Cependant, j'ai souvent lu sur
des problèmes de performances lorsque les champs sont
les valeurs null et été conseillé d'utiliser un
chaîne vide dans le cas où la valeur NULL est
en fait sémantiquement correct.
Je vais être tatillon sur le choix des mots pour un moment:
- Même si elle était un important facteur de performance, ce n'en est pas sémantiquement correct d'utiliser une valeur à la place de NULL. Dans SQL, NULL a un rôle sémantique pour désigner un manque ou inapplicable valeur. Les caractéristiques de performance de la valeur NULL dans un SGBDR mise en œuvre sont indépendants de cette. La performance peut varier d'une marque à l'autre ou à partir d'une version à l'autre, mais le but de NULL dans la langue est compatible.
En tout cas, je n'ai pas entendu parler de tout élément de preuve qu'NULL fonctionne mal. Je serais intéressé par toutes les références à des mesures de performance qui montrent nullable colonnes effectuer de pire que les non-nullable colonnes.
Je ne dis pas que je ne me trompe pas ou qu'il ne peut pas être vrai dans certains cas, mais seulement qu'il n'est pas significatif pour le rendre inactif suppositions. La Science n'est pas faite de conjecture; on a la preuve avec la répétabilité des mesures.
Les métriques de vous dire aussi par la façon dont beaucoup de la performance diffère, de sorte que vous pouvez porter un jugement quant à savoir si c'est quelque chose à la peine de s'inquiéter au sujet de. Qui est, l'impact pourrait être mesurables et différente de zéro, mais toujours insignifiant par rapport à une plus grande performance de facteurs, tels que correctement l'indexation des tables ou le dimensionnement de la base de données du cache.
Dans MySQL, les recherches pour la valeur NULL peut 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 |
+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+
Remarque c'est toujours pas une mesure de rendement. Je n'ai montré que vous pouvez utiliser un index lors de la recherche de la valeur NULL. Je vais faire valoir (il est vrai sans avoir mesuré, mais bon c'est juste StackOverflow) que l'avantage d'un indice éclipse toute éventuelle sanction lors de la recherche pour les NULS par rapport à une chaîne vide.
Ce n'est pas une conception correcte de la décision de choisir le zéro ou vide ou toute autre valeur à substituer à la valeur NULL. Vous devrez peut-être utiliser ces valeurs dans la colonne. C'est pourquoi NULL existe, comme une valeur qui est par définition en dehors du domaine de valeurs de tout type de données, de sorte que vous pouvez utiliser la gamme complète des valeurs des entiers ou des chaînes ou quoi que ce soit et avoir encore quelque chose pour signifier "aucun des valeurs ci-dessus."
