Conception de colonne SQL Server

Question

J'ai toujours essayé de rendre ma base de données sql aussi simple et compréhensible que possible. Jusqu'à maintenant j'utilisais toujours un nombre limité de colonnes, je crois que je n'en avais jamais plus de 20. Maintenant, il y a une chose qui me faciliterait la vie, si j'avais beaucoup plus de colonnes. Disons 200 colonnes. (pas de rangées). Qu'est-ce que tu en penses? Je veux juste savoir, si c'est une mauvaise idée, pas pourquoi je fais cela ou s'il y a d'autres possibilités, juste si quelqu'un a déjà vécu quelque chose comme ça et si c'est une mauvaise idée de le faire une table.

Answer 1

Je ne pense pas que ce soit en noir et blanc. Avoir une grande taille de rangée (impliquée par le grand nombre de colonnes) nuira aux performances (c'est-à-dire, plus d'E/S) - mais il y a des cas où un petit coup de performance à un endroit sera compensé par une performance accrue dans d'autres. Je dirais que cela dépend du nombre de lignes que vous attendez de cette table, de la fréquence à laquelle elle sera interrogée, du nombre de colonnes supplémentaires qui seront vraiment accessibles et de la façon dont elle sera comparée à votre conception alternative. termes d'efficacité et de complexité.

Answer 2

Luke--

Cela dépend vraiment du type de système que vous travaillez. Exemple dans les systèmes transactionnels, la plupart des tables ont au plus 50 colonnes ou presque sans attributs de données redondants (si vous avez une date de processus, vous n'avez pas besoin du mois de processus ou de l'année de processus en tant que colonne séparée). Ceci est bien sûr dû au fait que les enregistrements sont fréquemment mis à jour/insérés et que vous devez mettre à jour tous les attributs redondants chaque fois que vous mettez à jour une ligne. Dans les environnements Data Warehouse/reporting, pour les tables Dimension (qui possèdent les attributs d'une entité), il est généralement possible d'avoir 100 colonnes, car il peut y avoir différentes manières de catégoriser une entité donnée. Les mises à jour sont ici pas tellement un problème que les données sont généralement chargées une fois pendant les heures creuses, puis est utilisé principalement dans les sélections.

Jetez un oeil à ces liens pour en savoir plus ..

http://en.wikipedia.org/wiki/Database_normalization

http://en.wikipedia.org/wiki/Star_schema

La réponse est que cela dépend ... Si vous voulez un système parfaitement relationnel, alors peut-être 200 + colonnes est une sorte de drapeau rouge indiquant que vous devriez chercher à normaliser vos données (peut-être pas). Les mises à jour et les index sont deux choses qui devraient vous intéresser dans un tel système.

Answer 3

Moins de colonnes de plus petite largeur est préférable à beaucoup de colonnes et/ou de colonnes de grande largeur.

Pourquoi? Plus la taille des lignes est étroite, plus les lignes sont nombreuses sur une page de 8 Ko. Cela signifie que vous faites moins d'E/S et utilisez moins de mémoire pour mettre en mémoire tampon les pages. C'est toujours une bonne chose.

Dans ces (rares) cas où le domaine requiert de nombreux attributs sur un objet (avec la supposition d'un mappage de table objet 1-1), vous devez envisager de scinder en deux tables une relation 1-1, une contenant les colonnes fréquemment utilisées.