Les colonnes vides occupent-elles de l'espace dans une table?

J'ai une table qui contient des informations très basiques. Juste un titre et quelques champs de date. Il y a un champ appelé commentaires qui est varchar (4000) La plupart du temps, nous le laissons vide, mais parfois nous entrons une grande quantité de données ici. Est-ce vraiment une mauvaise conception? Ou est-ce juste légèrement inefficace?

Je suppose que la création d'un tableau séparé pour cette colonne serait préférable.

Remarque: il s'agit du serveur SQL 2008

Pour des performances plus prévisibles (et pour éviter d'avoir une variation élevée des lignes par page), je préférerais stocker ces données dans une table associée - surtout si elles ne sont remplies qu'un petit pourcentage du temps, et surtout si elles ne sont récupérées que dans certaines des requêtes. Les lignes où se trouve cette valeur NULLcontribuent à la surcharge d'espace, mais cela est minime. Plus important sera de savoir comment une page ne peut contenir que deux lignes et la page suivante peut contenir 500 lignes - cela peut vraiment avoir un impact sur les statistiques et vous feriez mieux de diviser cela afin qu'il soit stocké séparément et n'impacte pas toutes vos opérations sur la table de base.

Il prend un minimum d'espace lorsqu'il n'est pas utilisé

• un bit dans le bitmap NULL
• deux octets pour la longueur (qui sera zéro lorsque NULL)

Les frais généraux sont minimes et l'optimisation sera prématurée.

Jusqu'à ce que vous sachiez que vous avez un problème, conservez-le dans une seule table. Vous brisez KISS en introduisant des jointures externes et en ajoutant une surcharge lors de l'interrogation des données.

Voir /programming/3793022/how-to-come-to-limits-of-8060-bytes-per-row-and-8000-per-varchar-nvarchar-valu/3793265#3793265 pour plus

Je pense qu'un tableau séparé serait préférable pour améliorer la densité des pages et réduire la fragmentation, surtout si vous ne remplissez pas toujours ce champ.

• Une page de données contient environ 8000 octets
• Vous avez quelques lignes avec disons 100 octets et quelques lignes avec plus de 4000 octets
• Ces longues lignes seront sur une page par elles-mêmes, et le reste de la page est un espace "gaspillé" que votre base de données occupe mais ne contiendra probablement jamais de données
• Si vous ajoutez des données à ce long champ pour un enregistrement sur une page presque pleine, cela dépassera probablement la page et entraînera un pointeur vers la page avec le reste de l'enregistrement

Toutes ces pages vides et pointeurs conduisent à de mauvaises performances. Normalisez ce champ si vous le pouvez.

Cette question semble très similaire: les colonnes vides supplémentaires affectent-elles la taille de la table SQL de manière significative?

Il semble que la réponse soit oui, cela prend de la place, mais il existe un algorithme de compression pour les colonnes avec beaucoup de valeurs nulles.

En ce qui concerne le design, je pense qu'avoir une table externe liée à cela serait un design plus propre. Avoir une colonne avec des valeurs nulles fréquentes rend plus difficile pour les utilisateurs de la base de données car ils pourraient accidentellement utiliser une valeur nulle s'ils ne font pas attention. Par conséquent, le code utilisant la base de données devrait contenir une vérification des erreurs et il devient simplement laid à partir de là.

Tout ira bien - c'est déjà une colonne varchar, donc elle n'utilise de l'espace que lorsqu'elle contient des données. Si vous aviez beaucoup de colonnes de taille fixe nullable comme int, vous pourriez avoir des problèmes d'utilisation de l'espace.

En ce qui concerne le mettre dans une autre table, je ne me dérangerais pas. Vous pouvez également envisager d'utiliser varchar (max) et les options d'entrée / sortie de ligne. Encore une fois, probablement prématuré.