Je vais être pointilleux sur le choix des mots pendant un moment :
- Même s'il s'agissait d'un facteur de performance important, cela ne le rend pas sémantiquement correct d'utiliser une valeur au lieu de NULL. En SQL, NULL a un rôle sémantique, pour désigner une valeur manquante ou inapplicable. Les caractéristiques de performance de NULL dans une implémentation RDBMS donnée sont indépendantes de cela. Les performances peuvent varier d'une marque à l'autre ou d'une version à l'autre, mais l'objectif de NULL dans le langage est cohérent.
En tout cas, je n'ai entendu aucune preuve que NULL fonctionne mal. Je serais intéressé par toute référence à des mesures de performances qui montrent que les colonnes nullables fonctionnent moins bien que les colonnes non nullables.
Je ne dis pas que je ne me trompe pas ou que cela ne peut pas être vrai dans certains cas - juste que cela n'a pas de sens de faire des suppositions inutiles. La science n'est pas faite de conjectures; il faut montrer des preuves avec des mesures reproductibles.
Les statistiques vous indiquent également combien les performances diffèrent, vous pouvez donc juger si cela vaut la peine de s'inquiéter. Autrement dit, l'impact peut être mesurable et non nul, mais toujours insignifiant par rapport à des facteurs de performances plus importants, tels que l'indexation correcte des tables ou le dimensionnement du cache de votre base de données.
Dans MySQL, les recherches de NULL peuvent bénéficier d'un index :
mysql> CREATE TABLE foo (
i INT NOT NULL,
j INT DEFAULT NULL,
PRIMARY KEY (i),
UNIQUE KEY j_index (j)
);
mysql> INSERT INTO foo (i, j) VALUES
(1, 1), (2, 2), (3, NULL), (4, NULL), (5, 5);
mysql> EXPLAIN SELECT * FROM foo WHERE i = 3;
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| 1 | SIMPLE | foo | const | PRIMARY | PRIMARY | 4 | const | 1 | |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
mysql> EXPLAIN SELECT * FROM foo WHERE j IS NULL;
+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+
| 1 | SIMPLE | foo | ref | j_index | j_index | 5 | const | 2 | Using where |
+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+
Notez que ce n'est toujours pas une mesure de performance. J'ai seulement montré que vous pouvez utiliser un index lors de la recherche de NULL. Je vais affirmer (certes sans avoir mesuré, mais bon c'est juste StackOverflow) que l'avantage d'un index éclipse toute pénalité possible lors de la recherche de NULL par rapport à une chaîne vide.
Ce n'est pas une décision de conception correcte de choisir zéro ou vide ou toute autre valeur à remplacer par NULL. Vous devrez peut-être utiliser ces valeurs comme significatives dans la colonne. C'est pourquoi NULL existe, en tant que valeur qui est par définition en dehors du domaine des valeurs de tout type de données, vous pouvez donc utiliser la gamme complète de valeurs d'entiers ou de chaînes ou autre et avoir toujours quelque chose à signifier "aucune des valeurs ci-dessus. "
