Table avec beaucoup de colonnes

Question

Si ma table contient un nombre important de colonnes (plus de 80), dois-je la diviser en plusieurs tables avec une relation un à un ou la conserver telle quelle? Pourquoi? Ma principale préoccupation est la performance.

PS - ma table est déjà en 3ème forme normale.

PS2 - J'utilise MS SQL Server 2008.

PS3 - Je n'ai pas besoin d'accéder à toutes les données d'un tableau à la fois, mais plutôt d'avoir 3 catégories de données différentes dans ce tableau, auxquelles j'accède séparément. Cela ressemble à quelque chose comme: préférences de membre, compte de membre, profil de membre.

Answer 1

80 colonnes ne sont vraiment pas si nombreuses ...

Je ne m'en inquiéterais pas du point de vue des performances. Avoir une seule table (si vous utilisez généralement toutes les données de vos opérations standard) sera probablement plus performant que plusieurs tables avec des relations 1-1, en particulier si vous indexez correctement.

Cela m'inquiéterait (potentiellement) du point de vue de la maintenance. Plus il y a de colonnes de données dans une seule table, moins le rôle de cette table dans votre grand schéma devient compréhensible. De même, si vous n'utilisez généralement qu'un petit sous-ensemble de données et que les 80 colonnes ne sont pas toujours obligatoires, le fractionnement en deux tables ou plus peut améliorer les performances.

Answer 2

Re la question de la performance - cela dépend. Plus une ligne est grande, moins il est possible de lire les lignes d'un disque en une lecture. Si vous avez beaucoup de lignes et que vous voulez pouvoir lire très rapidement les informations de base de la table, il peut être intéressant de les séparer en deux tables - une avec de petites lignes contenant uniquement les informations de base pouvant être lues rapidement. et une table supplémentaire contenant toutes les informations que vous utilisez rarement que vous pouvez rechercher en cas de besoin.

Answer 3

Passons à autre chose, à partir d'une maintenance & amp; En testant le point de vue, si, comme vous le dites, vous avez 3 groupes de données distincts dans la même table, même si tous ont le même identifiant unique (par exemple, member_id), il peut être judicieux de la scinder en plusieurs tables.

Si vous devez ajouter des champs pour indiquer les détails de votre profil dans la table d'informations sur les membres, voulez-vous vraiment courir le risque de devoir tester à nouveau les préférences & amp; Les détails du compte de votre application ainsi que pour éviter tout impact.

Également à des fins d'audit, si vous souhaitez suivre le dernier ID utilisateur / horodatage pour modifier les données d'un membre. Si l'application admin permet la mise à jour séparée des préférences / des détails du compte / des détails du profil, il est logique de les placer dans des tableaux distincts pour suivre plus facilement les mises à jour.

Pas tout à fait une réponse SQL / Performance, mais peut-être quelque chose à regarder à partir d'une base de données & amp; Conception d'applications pov

Answer 4

Dépend de la nature de ces colonnes. Si vous avez des champs dupliqués codés en dur tels que Colour1, Colour2, Colour3, ils sont alors candidats aux tables enfant. Ma règle générale est que s’il ya plus d’un champ du même type (Couleur), vous pouvez aussi bien en coder N, et non un nombre fixe.

Rob.

Answer 5

1-1 peut être plus facile si vous avez déclaré Member_Info; Member_Pref; Member_Profile. Avoir trop de colonnes peut le faire fonctionner si vous voulez beaucoup de varchar (255), car vous pouvez dépasser la limite de taille de lignes, ce qui rend les choses trop confuses.

Assurez-vous simplement que vous avez les contraintes de clé de forge correctes, etc., afin qu'il y ait toujours une ligne dans chaque table avec le même nom de membre

.