Wow, la bonne réponse "N'autorisez pas les valeurs NULL lorsque vous n'êtes pas obligé de le faire, car elles dégradent les performances" est en quelque sorte la dernière réponse notée. Je vais le voter et élaborer. Lorsqu'un SGBDR autorise les valeurs NULL pour une colonne non fragmentée, cette colonne est ajoutée à une image bitmap qui indique si la valeur est NULL pour chaque ligne. Ainsi, en ajoutant une capacité NULL à une colonne d'une table où toutes les colonnes n'autorisent pas les valeurs NULL, vous augmentez l'espace de stockage requis pour enregistrer la table. De plus, vous demandez au SGBDR de lire et d’écrire dans le bitmap, ce qui nuit aux performances de toutes les opérations.
En outre, dans un certain nombre de cas, autoriser des valeurs NULL rompra 3NF. Bien que je ne sois pas un collant pour 3NF comme bon nombre de mes collègues, considérons le scénario suivant:
Dans la table Personne, il existe une colonne, appelée DateOfDeath, qui est nullable. Si une personne est décédée, son DateOfDeath sera renseigné, sinon, il sera laissé à NULL. Il existe également une colonne de bits non nullable appelée IsAlive. Cette colonne est définie sur 1 si la personne est en vie et sur 0 si la personne est morte. La grande majorité des procédures stockées utilisent la colonne IsAlive, elles ne s’intéressent que si une personne est en vie, et non leur DateOfDeath.
Cependant, la colonne IsAlive interrompt la normalisation de la base de données, car elle est complètement dérivable de DateOfDeath. Mais comme IsAlive est câblé dans la majorité des fournisseurs de services, la solution simple consiste à rendre DateOfDeath non nullable et à attribuer une valeur par défaut à la colonne dans le cas où la personne est toujours en vie. Les quelques SP qui utilisent DateOfDeath peuvent ensuite être réécrits pour vérifier la colonne IsAlive et n'honorer DateOfDeath que si la personne n'est pas en vie. Encore une fois, étant donné que la majorité des fournisseurs de services s'intéressent uniquement à IsAlive (un peu) et non à DateOfDeath (une date), l’utilisation de ce modèle accélère considérablement l’accès.
Un script T-SQL utile pour rechercher des colonnes Nullable sans NULL dans tous les schémas est:
select 'IF NOT EXISTS (SELECT 1 FROM ' + QUOTENAME(s.name) + '.' + QUOTENAME(t.name) + ' WHERE ' + QUOTENAME(c.name) + ' IS NULL)
AND (SELECT COUNT(*) FROM ' + QUOTENAME(s.name) + '.' + QUOTENAME(t.name) + ') > 1 PRINT ''' + s.name + '.' + t.name + '.' + REPLACE(c.name, '''', '''''') + ''''
from sys.columns c
inner join sys.tables t ON c.object_id = t.object_id
inner join sys.schemas s ON s.schema_id = t.schema_id
where c.is_nullable = 1 AND c.is_computed = 0
order by s.name, t.name, c.name;
Si vous exécutez cette opération sur une copie de votre base de données de production, vous pouvez trouver les colonnes de développeurs marquées comme autorisant les valeurs NULL ne contenant pas de valeur NULL dans la pratique. La grande majorité d'entre eux peuvent être marqués comme NOT NULL, augmentant ainsi les performances et diminuant l'espace de stockage.
Il se peut qu'il ne soit pas possible d'éliminer tous les NULL de toutes les tables tout en conservant une conception propre, mais l'élimination du plus grand nombre possible de NULL présente un avantage considérable. L'optimiseur fonctionne beaucoup plus rapidement avec ces informations et si vous pouvez éliminer toutes les valeurs NULL d'une table, vous pouvez récupérer une quantité considérable d'espace de stockage.
Je sais que les administrateurs de bases de données ne pensent pas vraiment aux performances, mais vous ne pouvez utiliser qu'une solution limitée, avec une quantité de mémoire et de puissance de processeur maximale. Vous devrez commencer à penser à la conception physique et logique. .
Notez également que cela ne concerne que les vrais SGBDR et que je base la partie technique de mes réponses sur SQL Server. Le T-SQL répertorié pour rechercher les colonnes Nullable sans NULL provient également de SQL Server.