NULL ou NOT NULL par défaut?


41

Dans MySQL, est-il préférable de toujours autoriser les valeurs NULL sauf si vous savez qu'un champ est obligatoire, ou de toujours les utiliser Not Nullsauf si vous savez qu'un champ contiendra des NULL? Ou n'est-ce pas important?

Je sais que dans certains SGBD, ils disent utiliser Not Nullle plus possible, car autoriser les valeurs NULL nécessite un bit supplémentaire (ou un octet?) Par enregistrement pour stocker le statut Null.


1
Vous devez autoriser NULLsi et seulement si la NULLvaleur a une interprétation de la chose que vous modélisez.
jameshfisher

Réponses:


25

Dans la plupart des bases de données, une NOT NULLcolonne sera plus efficace en termes de données stockées pour la raison que vous indiquez, et également plus efficace pour interroger et indexer. Ainsi, à moins que vous ne souhaitiez autoriser des valeurs NULL dans une colonne, vous devez explicitement les interdire.

Il y aura une légère implication sur les performances, car les NOT NULLcontraintes supplémentaires devront éventuellement être vérifiées pour chaque ligne affectée par un INSERT ou un UPDATE, mais comme la plupart des bases de données sont relativement légères en lecture et très lues, ce n'est probablement pas un problème De toute façon, il est peu probable que du temps supplémentaire soit perçu, car il s’agit d’une opération liée au processeur, où le reste de l’opération d’insertion / mise à jour sera lié à l’entrée / sortie et donc un goulot d'étranglement beaucoup plus important) et qui vous laisse un peu de liberté. "vérification des données afin que votre code (ou le code des autres personnes) ne puisse pas mettre accidentellement des valeurs NULL là où un autre code ne les attend pas et peut donc donner des résultats incorrects en leur présence.

Edit: Comme Peter le fait remarquer dans son commentaire, ce qui précède est un généralisme et pourrait ne pas s’appliquer à tous les DMBS, bien que je sois à peu près sûr que c’est le cas pour mysql et mssql. D'autres complications dans le domaine pourraient inclure des fonctionnalités telles que les tables éparses (telles que MSSQL 2008 implémentée) qui modifieront la dynamique de performance des colonnes (non) nullables.


8
Ce n'est pas nécessairement vrai dans PostgreSQL. Les colonnes nuls permettent d'économiser de l'espace, ce qui peut améliorer la vitesse, et le temps de traitement devrait être à peu près le même.
Peter Eisentraut

4
Cela n’est pas vrai non plus pour Oracle. De plus, contrairement à MySql, Oracle n’indexe pas les valeurs NULL, ce qui vous permet de réduire la taille de vos index. Voir stackoverflow.com/questions/289001/does-mysql-index-null-values
Leigh Riffel

8

Vous devez laisser votre conception de schéma et les exigences d’application guider cette décision. Les différences de performances ne sont probablement pas perceptibles dans les deux cas dans la plupart des cas.


3
Encore une fois, le meilleur moyen de savoir avec certitude est de profiler et de tester.
jcolebrand

Je ferais attention à de telles déclarations générales: si vous écrivez 10 millions de lignes chaque nuit dans un tableau via un processus ETL et que ce tableau comporte de nombreux champs non nuls contraints, vous constaterez les effets sur les performances.
ScottCher

1
+1: Ce n'est peut-être pas le cas pour toutes les applications, mais pour ce que je fais, obtenir des données cohérentes / correctes est plus important que d'économiser de l'espace ou de perdre de la vitesse.
jp
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.