Les valeurs NULL dans une base de données relationnelle sont-elles correctes?

Question

Il existe une école de pensée selon laquelle les valeurs nulles ne devraient pas être autorisées dans une base de données relationnelle. En d'autres termes, l'attribut d'une table (colonne) ne doit pas autoriser les valeurs NULL. Venant d'un contexte de développement logiciel, je ne comprends vraiment pas cela. Il semble que si null est valide dans le contexte de l'attribut, il devrait être autorisé. Ceci est très courant en Java où les références d'objet sont souvent nulles. N'ayant pas une vaste expérience de base de données, je me demande si quelque chose me manque ici.

Answer 1

Les valeurs null sont négativement du point de vue de la normalisation de base de données. L'idée étant que si une valeur peut être rien, alors vous devez vraiment être répartis dans une autre clairsemée le tableau de telle sorte que vous n'avez pas besoin de lignes pour les éléments qui n'ont aucune valeur.

C'est un effort pour s'assurer que toutes les données sont valides et mis en valeur.

Dans certains cas, avoir un champ nul est utile, mais, surtout lorsque vous voulez éviter encore une autre rejoindre pour des raisons de performances (bien que cela ne devrait pas être un problème si le moteur de base de données est configuré correctement, sauf dans des haute performance scénarios).

Answer 2

Un argument contre les valeurs null, c'est qu'ils n'ont pas bien définie de l'interprétation. Si un champ est null, ce qui pourrait être interprété comme une des opérations suivantes:

• La valeur est "Rien" ou "ensemble Vide"
• Il n'y a pas de valeur qui a du sens pour ce champ.
• La valeur est inconnue.
• La valeur n'a pas été saisi.
• La valeur est une chaîne vide (pour les bases de données qui ne font pas la distinction entre les valeurs null et les cordes à vide).
• Certains spécifiques à l'application de la signification (par exemple, "Si la valeur est null, alors l'utilisation d'une valeur par défaut.")
• Une erreur s'est produite, provoquant le terrain pour avoir une valeur nulle lorsqu'il ne devrais vraiment pas.

Certains créateurs de schémas de la demande que toutes les valeurs et les types de données doit avoir bien défini les interprétations, par conséquent, les valeurs null sont mauvais.

Answer 3

Les marqueurs nuls sont bons. Vraiment, ils sont.

Answer 4

Il dépend.

Aussi longtemps que vous comprenez pourquoi vous permettant d' NULLs dans la base de données (le choix doit être fait sur une, colonne par colonne) ET à la façon de les interpréter, de les ignorer ou de les traiter autrement avec eux, ils sont beaux.

Par exemple, une colonne comme NUM_CHILDREN - que faites-vous si vous ne connaissez pas la réponse, il devrait être NULL. Dans mon esprit, il n'y a pas d'autre meilleure option pour cette colonne design (même si vous avez un indicateur pour déterminer si l' NUM_CHILDREN colonne est valide, vous pouvez toujours avoir une valeur dans cette colonne).

D'autre part, si vous ne voulez pas autoriser NULLs et des valeurs réservées pour certains cas (au lieu de drapeaux), à l'instar de -1 pour le nombre d'enfants quand il est vraiment inconnu, vous devez les traiter d'une manière similaire, en termes de conventions, de la documentation, etc.

Donc, en fin de compte, les questions doivent être abordées avec les conventions, de la documentation et de la cohérence.

L'alternative, car apparemment, épousée par Adam Davis dans la réponse ci-dessus, de normaliser les colonnes éparse (ou pas si rares, dans le cas de l' NUM_CHILDREN exemple ou n'importe quel exemple, où la plupart des données ont des valeurs connues) des tables, tout en mesure d'éliminer tous les Zéros, n'est pas réalisable dans la pratique générale.

Dans de nombreux cas où un attribut est inconnue, il n'a guère de sens à se joindre à une autre table pour chaque et chaque colonne, ce qui pourrait permettre d' NULLs dans un design simple et sobre. La surcharge de jointures, les besoins d'espace pour les theprimary clés ont peu de sens dans le monde réel.

Cela apporte à l'esprit la façon dont les doublons de lignes peuvent être éliminés par l'ajout d'une colonne cardinalité, alors que théoriquement il résout le problème de ne pas avoir une clé unique, dans la pratique, c'est parfois impossible, par exemple, de données à grande échelle. Les puristes sont ensuite rapide pour suggérer un substitut PK au lieu de cela, pourtant, l'idée que la signification de substitution peuvent faire partie d'un n-uplet (ligne) dans une relation (table) est risible du point de vue de la théorie relationnelle.

Answer 5

Il n'y a rien de mal à utiliser NULL pour les champs de données. Vous devez faire attention lorsque vous définissez les clés sur null. Les clés primaires ne doivent jamais être NULL. Les clés étrangères peuvent être nulles mais vous devez faire attention à ne pas créer d'enregistrements orphelins.

Si quelque chose est "non existant", vous devez utiliser NULL au lieu d'une chaîne vide ou d'un autre type d'indicateur.