Combien de colonnes sont trop nombreuses pour une table SQL Server 2005?

Question

J'ai une demande pour permettre à une table dynamique d'avoir 1000 colonnes (sélectionnées au hasard par mes utilisateurs finaux). Cela semble être une mauvaise idée pour moi. C'est une table personnalisable donc elle aura un mélange de colonnes varchar(200) et float (le flottant correspond le mieux au type double C++ des applications). Cette base de données est principalement un index pour une application héritée et sert de référentiel de rapports. Ce n'est pas le système d'enregistrement. L'application possède des milliers de points de données dont très peu pourraient être normalisés.

Toutes les idées quant à ce que les conséquences sur les performances de ce sont? Ou une taille de table idéale pour diviser cela aussi?

Comme je ne sais pas ce que les champs de 20k valeur de choix des utilisateurs finaux choisir normalisant les tables est impossible. Je peux séparer ces données à plusieurs tables que je devrais gérer dynamiquement (les champs peuvent être ajoutés ou affaissés, les lignes sont ensuite supprimées et le système d'enregistrement est analysé pour remplir la table.) Ma préférence est de repousser normaliser tous les 20k bits de données. Mais je ne vois pas cela se produire.

Answer 1

Cette odeurs comme une mauvaise conception pour moi.

choses à considérer:

Est-ce que la plupart de ces colonnes est contenir des valeurs NULL?

Nombreux seront-ils nommés Property001, Property002, Property003, etc ...?

Si oui, je vous recommande de repenser la normalisation de vos données.

Answer 2

En règle générale: la plus large de la table plus lente est la performance. De nombreuses tables minces sont préférables à un gros désordre d'une table.

Si votre table est que large, il est presque certainement un problème de conception. Il n'y a pas de véritable règle sur le nombre de fois préférable, je n'ai jamais vraiment rencontré de tables avec plus de 20 colonnes dans le monde réel. Juste groupe par relation. C'est un SGBDR après tout.

Answer 3

Cela ressemble énormément. Je m'assurerais d'abord que les données sont normalisées. Cela pourrait faire partie de votre problème. Quel type de but ces données vont-elles servir? Est-ce pour les rapports? Les données vont-elles changer?

Je pense une table qui est une grande performance cauchemar et sage entretien.

Answer 4

C'est trop. Vous avez plus de 50 colonnes de largeur et vous demandez des problèmes de performances, de maintenance du code et de résolution des problèmes en cas de problème.

Answer 5

de la documentation SQL2005:

SQL Server 2005 peut contenir jusqu'à deux milliards de tables par base de données et 1.024 colonnes par table. (...) Le nombre maximal d'octets par ligne est de 8 060. Cette restriction est assouplie pour les tables avec des colonnes varchar, nvarchar, varbinary ou sql_variant qui font que la largeur totale de la table définie dépasse 8 060 octets. Les longueurs de chacune de ces colonnes doivent toujours tomber dans la limite de 8 000 octets, mais leurs largeurs combinées peuvent dépasser la limite de 8 060 octets dans une table.

quelle est la fonctionnalité de ces colonnes? pourquoi ne pas mieux les diviser en table principale, les propriétés (tables de recherche) et les valeurs?

Answer 6

MS SQL Server a une limite de 1024 colonnes par table, vous êtes si va être en cours d'exécution sur le bord de ce. En utilisant les colonnes varchar (200), vous pourrez dépasser la limite de 8 k octets par ligne, puisque SQL stockera 8k sur la page de données, puis débordera les données en dehors de la page.

SQL 2008 a ajouté des colonnes fragmentées pour des scénarios comme celui-ci - où vous auriez beaucoup de colonnes avec des valeurs nulles.

en utilisant des colonnes Sparse http://msdn.microsoft.com/en-us/library/cc280604.aspx

Answer 7

Cela aura d'énormes problèmes de performance et de données. Il a probablement besoin d'être normalisé.

Alors que sql server vous permet de créer une table qui a plus de 8060 octets inteh ligne, il ne vous permet de stocker plus de données que celle en elle. Vous pourriez avoir des données tronquées de manière inattendue (et pire encore, plusieurs mois plus tard, cela pourrait se produire, et à ce moment-là, fixer cette monstruosité est à la fois urgent et extrêmement difficile).

L'interrogation de ce sera également un vrai problème. Comment sauriez-vous laquelle des 1000 colonnes pour rechercher les données? Est-ce que chaque requête devrait demander toutes les 1000 colonnes de la clause where?

Et l'idée que ce serait personnalisable par l'utilisateur est vraiment effrayante. Pourquoi l'utilisateur aurait-il besoin de 1000 champs pour le personnaliser? La plupart des applications que j'ai vues qui permettent à l'utilisateur de personnaliser certains champs définissent une petite limite (généralement inférieure à 10). S'il y a tellement de choses à personnaliser, alors l'application n'a pas bien défini ce dont le client a réellement besoin.

Parfois, en tant que développeur, vous devez simplement vous lever et dire non, c'est une mauvaise idée. C'est l'une de ces fois.

Quant à ce que vous faites à la place qui devraient (autres que Normaliser), je pense que nous aurions besoin de plus d'informations pour vous diriger dans la bonne direction.

Et BTW, flotteur est un type de données et ne doit pas inexact être utilisé dans les champs où les calculs ont lieu, sauf si vous aimez des résultats incorrects.

Answer 8

Chaque fois que vous ressentez le besoin de demander quelles sont les limites du système, vous avez un problème de conception.

Si vous demandiez "Combien de caractères puis-je insérer dans un varchar?" alors vous ne devriez pas utiliser varchars du tout.

Si vous voulez sérieusement savoir si 1000 colonnes est correct, alors vous avez désespérément besoin de réorganiser les données. (Normalisation)

Answer 9

Avez-vous pensé l'affichage de votre finale (1000 colonnes) tableau à la suite d'une requête de tableau croisé? Votre table d'origine aurait alors juste quelques colonnes mais plusieurs milliers de dossiers.

Pouvez-vous élaborer sur votre problème? Je pense que personne ne comprend vraiment pourquoi vous avez besoin de ces 1000 colonnes!

Answer 10

Je suis en désaccord avec tout le monde ici ..... Je sais que cela semble fou, mais en utilisant des tables avec des centaines de colonnes est la meilleure chose que j'ai jamais fait.

Oui, de nombreuses colonnes ont souvent des valeurs nulles; Oui, je pourrais le normaliser à quelques tables et transposer; Oui, il est inefficace

Cependant, il est incroyablement rapide et facile d'analyser les données de colonne de manière sans fin différentes

gaspilleur et inélégante - vous ne serez jamais construire quoi que ce soit aussi utile!