Les valeurs nulles dans une base de données relationnelle sont-elles correctes?
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. Autrement dit, l'attribut (colonne) d'une table ne doit pas autoriser les valeurs nulles. Venant d'une formation en développement logiciel, je ne comprends vraiment pas cela. Il semble que si null est valide dans le contexte de l'attribut, alors il devrait être autorisé. C'est très courant dans Java où les références aux objets sont souvent nulles. N'ayant pas une grande expérience de base de données, je me demande si je manque quelque chose ici.
Les valeurs nulles sont vues négativement du point de vue de la normalisation de la base de données. L'idée étant que si une valeur ne peut être rien, alors vous devriez vraiment la diviser en une autre table clairsemée de sorte que vous n'avez pas besoin de lignes pour les éléments qui n'ont pas de valeur.
C'est un effort pour s'assurer que toutes les données sont valides et valorisées.
Dans certains cas, avoir un champ nul est utile, cependant, surtout lorsque vous voulez éviter une autre jointure pour des raisons de performances (bien que cela ne devrait pas être un problème si le moteur de base de données est correctement configuré, sauf dans des scénarios extraordinairement performants.)
-Adam
Un argument contre les nulls est qu'ils n'ont pas d'interprétation bien définie. Si un champ est nul, cela pourrait être interprété comme l'un des éléments suivants:
- La valeur est "Nothing" ou "Empty set"
- Aucune valeur n'a de sens pour ce champ.
- La valeur est inconnue.
- La valeur n'a pas encore été saisie.
- La valeur est une chaîne vide (pour les bases de données qui ne distinguent pas les valeurs nulles et les chaînes vides).
- Une signification spécifique à l'application (par exemple, "Si la valeur est nulle, utilisez une valeur par défaut.")
- Une erreur s'est produite, ce qui a donné au champ une valeur nulle alors qu'il ne devrait vraiment pas.
Certains concepteurs de schéma exigent que toutes les valeurs et tous les types de données aient des interprétations bien définies, donc les valeurs NULL sont mauvaises.
Les marqueurs nuls sont très bien. Vraiment, ils le sont.
Ça dépend.
Tant que vous comprenez pourquoi vous autorisez NULLs dans la base de données (le choix doit être fait sur une base par colonne) ET comment vous allez interpréter, ignorer ou traiter autrement eux, ils vont bien.
Par exemple, une colonne comme NUM_CHILDREN - que faites-vous si vous ne connaissez pas la réponse - ce devrait être NULL. Dans mon esprit, il n'y a pas d'autre meilleure option pour la conception de cette colonne (même si vous avez un indicateur pour déterminer si le NUM_CHILDREN la colonne est valide, vous devez toujours avoir une valeur dans cette colonne).
D'un autre côté, si vous n'autorisez pas NULLs et avez des valeurs réservées spéciales pour certains cas (au lieu de drapeaux), comme -1 pour le nombre d'enfants quand il est vraiment inconnu, vous devez les traiter dans d'une manière similaire, en termes de conventions, de documentation, etc.
Donc, en fin de compte, les problèmes doivent être traités avec des conventions, de la documentation et de la cohérence.
L'alternative, telle qu'apparemment apparue par Adam Davis dans la réponse ci-dessus, de normaliser les colonnes sur clairsemées (ou pas si clairsemées, dans le cas du NUM_CHILDREN exemple ou tout autre exemple où la plupart des données ont des valeurs connues), tout en étant capable d'éliminer tous les NULL, n'est pas réalisable en pratique générale.
Dans de nombreux cas où un attribut est inconnu, cela n'a pas de sens de se joindre à une autre table pour chaque colonne, ce qui pourrait autoriser NULLs dans une conception plus simple. Les frais généraux des jointures, l'espace requis pour les clés primaires n'ont guère de sens dans le monde réel.
Cela évoque la façon dont les lignes en double peuvent être éliminées en ajoutant une colonne de cardinalité, alors que cela résout théoriquement le problème de ne pas avoir de clé unique, dans la pratique, ce qui est parfois impossible - par exemple, dans les données à grande échelle. Les puristes sont ensuite prompts à suggérer un PK de substitution à la place, mais l'idée qu'un substitut sans signification peut faire partie d'un Tuple (ligne) dans une relation (tableau) est risible du point de vue de la théorie relationnelle.
Il existe plusieurs objections différentes à l'utilisation de NULL. Certaines des objections sont basées sur la théorie des bases de données. En théorie, il n'y a pas de différence entre la théorie et la pratique. En pratique, il y en a.
Il est vrai qu'une base de données entièrement normalisée peut se passer de NULLS. Tout endroit où une valeur de données doit être omise est un endroit où une ligne entière peut être omise sans perte d'informations.
Dans la pratique, la décomposition des tables dans cette mesure ne sert à rien et la programmation nécessaire pour effectuer des opérations CRUD simples sur la base de données devient plus fastidieuse et sujette aux erreurs, plutôt que moins.
Il y a des endroits où l'utilisation de NULLS peut causer des problèmes: ceux-ci tournent essentiellement autour de la question suivante: que signifient réellement les données manquantes? Tout ce qu'un NULL transmet est qu'il n'y a pas de valeur stockée dans un champ donné. Mais les inférences que les programmeurs d'applications tirent des données manquantes sont parfois incorrectes, ce qui pose beaucoup de problèmes.
Des données peuvent manquer dans un emplacement pour diverses raisons. Voici quelques-uns:
Les données ne sont pas applicables dans ce contexte. par exemple. prénom du conjoint pour une personne seule.
L'utilisateur d'un formulaire de saisie de données a laissé un champ vide et l'application n'a pas besoin d'une entrée dans le champ.
Les données sont copiées dans la base de données à partir d'une autre base de données ou fichier, et il y avait des données manquantes dans la source.
Il existe une relation facultative codée dans une clé étrangère.
Une chaîne vide a été stockée dans une base de données Oracle.
Voici quelques conseils pour éviter les NULLS:
Si au cours de la programmation normale attendue, les rédacteurs de requêtes doivent écrire beaucoup de code ISNULL, NV, COALESCE ou similaire afin de substituer une valeur valide au NULL. Parfois, il vaut mieux faire la substitution au moment du magasin, à condition que ce qui est stocké soit "réalité".
Si les décomptes sont susceptibles d'être désactivés car des lignes contenant un NULL ont été comptées. Souvent, cela peut être évité en sélectionnant simplement count (MyField) au lieu de count (*).
Voici un endroit où vous vous habituerez mieux à NULLS et programmez en conséquence: chaque fois que vous commencez à utiliser des jointures externes, comme LEFT JOIN et RIGHT JOIN. Le point entier derrière une jointure externe par opposition à une jointure interne est d'obtenir des lignes lorsque des données correspondantes sont manquantes. Les données manquantes seront données comme NULLS.
Ma conclusion: ne rejetez pas la théorie sans la comprendre. Mais apprenez quand s'écarter de la théorie et comment la suivre.
Il n'y a rien de mal à utiliser NULL pour les champs de données. Vous devez être prudent 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 "inexistant", vous devez utiliser NULL au lieu d'une chaîne vide ou d'un autre type d'indicateur.
Au lieu d'écrire tous les problèmes de NULL, et de la logique tristate vs booléenne, etc. - je vais offrir ce conseil concis:
N'autorisez pas NULL dans vos colonnes jusqu'à ce que vous vous trouviez à ajouter une valeur magique pour représenter les données manquantes ou incomplètes.
Puisque vous posez cette question, vous devez être très prudent dans votre approche de NULL. Il y a beaucoup d'écueils non évidents. En cas de doute, n'utilisez pas NULL.
Il existe une autre alternative à l'utilisation de "N/A" ou "N/K" ou de la chaîne vide - une table séparée.
Par exemple. si nous pouvons ou non connaître le numéro de téléphone d'un client:
CREATE TABLE Customer (ID int PRIMARY KEY, Name varchar(100) NOT NULL, Address varchar(200) NOT NULL);
CREATE TABLE CustomerPhone (ID int PRIMARY KEY, Phone varchar(20) NOT NULL, CONSTRAINT FK_CustomerPhone_Customer FOREIGN KEY (ID) REFERENCES Customer (ID));
Si nous ne connaissons pas le numéro de téléphone, nous n'ajoutons simplement pas de ligne au deuxième tableau.
Je dirais que Nulls devrait certainement être utilisé. Il n'y a pas d'autre bonne façon de représenter le manque de données. Par exemple, il serait incorrect d'utiliser une chaîne vide pour représenter une ligne d'adresse manquante, ou il serait erroné d'utiliser 0 pour représenter un élément de données d'âge manquant. Parce qu'une chaîne vide et 0 sont des données. Null est le meilleur moyen de représenter un tel scénario.
Ne sous-estimez pas la complexité que vous créez en rendant un champ NULLable. Par exemple, la clause where suivante semble correspondre à toutes les lignes (les bits ne peuvent être que 1 ou 0, n'est-ce pas?)
where bitfield in (1,0)
Mais si le champ de bits est NULLable, il en manquera. Ou prenez la requête suivante:
select * from mytable
where id not in (select id from excludetable)
Maintenant, si la table d'exclusion contient un null et un 1, cela se traduit par:
select * from mytable
where id <> NULL and id <> 1
Mais "id <> NULL" est faux pour n'importe quelle valeur de id, donc cela ne retournera jamais aucune ligne. Cela surprend même les développeurs de bases de données expérimentés par surprise.
Étant donné que la plupart des gens peuvent être pris au dépourvu par NULL, j'essaye de l'éviter quand je le peux.
C'est une énorme boîte de vers, car NULL peut signifier tellement de choses:
- Pas de date de décès car la personne est toujours en vie.
- Pas de numéro de portable car nous ne savons pas ce que c'est ou même s'il existe.
- Pas de numéro de sécurité sociale parce que cette personne sait n'en avoir pas.
Certains d'entre eux peuvent être évités par la normalisation, certains d'entre eux peuvent être évités par la présence d'une valeur dans cette colonne ("N/A"), certains d'entre eux peuvent être atténués en ayant une colonne séparée pour expliquer la présence du NULL ("N/K", "N/A", etc.).
C'est aussi une boîte de vers car la syntaxe SQL nécessaire pour les trouver est différente de celle des valeurs non nulles, il est difficile de les joindre et ils ne sont généralement pas inclus dans les entrées d'index.
Pour la première raison, vous trouverez des cas où une valeur nulle est inévitable.
Pour cette dernière raison, vous devez toujours faire de votre mieux pour minimiser leur nombre.
Quoi qu'il en soit, utilisez toujours les contraintes NOT NULL pour éviter les valeurs NULL lorsqu'une valeur est requise.
Le principal problème avec les valeurs NULL est qu'elles ont une sémantique spéciale qui peut produire des résultats inattendus avec des comparaisons, des agrégats et des jointures.
Rien n'est jamais égal à null, et rien n'est jamais égal, supérieur ou inférieur à null, vous devez donc définir null à une valeur d'espace réservé si vous voulez faire une comparaison en bloc.
C'est également un problème sur les clés composites qui peuvent être utilisées dans une jointure. Lorsque la clé naturelle comprend une colonne nullable, vous pouvez envisager d'utiliser une clé synthétique.
Les valeurs nulles peuvent être supprimées, ce qui n'est peut-être pas la sémantique souhaitée.
Les valeurs nulles dans une colonne contre laquelle vous pouvez joindre élimineront les lignes d'une jointure interne. En général, c'est probablement le comportement souhaité, mais il peut poser des pièges à éléphants pour les personnes qui font des rapports.
Il y a pas mal d'autres subtilités aux nulls. SQL pour Smarties de Joe Celko a un chapitre entier sur le sujet et est un bon livre et mérite d'être lu de toute façon. Voici quelques exemples d'endroits où les valeurs nulles sont une bonne solution:
Relations facultatives dans lesquelles une entité jointe peut ou non être présente. Null est le seul moyen de représenter une relation facultative sur une colonne de clé étrangère.
Colonnes que vous souhaiterez peut-être utiliser pour annuler la suppression des décomptes.
Valeurs numériques facultatives (par exemple devise) qui peuvent ou non être présentes. Il n'y a pas de valeur d'espace réservé efficace pour "non enregistré" dans les systèmes numériques (en particulier lorsque zéro est une valeur légale), donc null est vraiment le seul bon moyen de le faire.
Quelques exemples d'endroits où vous voudrez peut-être éviter d'utiliser des valeurs nulles car elles sont susceptibles de provoquer des bogues subtils.
Valeurs "non enregistrées" sur les champs de code avec un FK par rapport à une table de référence. Utilisez une valeur d'espace réservé pour que vous (ou un analyste métier aléatoire au bout du compte) ne supprimiez pas par inadvertance des lignes des jeux de résultats lorsque vous effectuez une requête sur la base de données.
Champs de description où rien n'a été entré - chaîne nulle (
'') fonctionne très bien pour cela. Cela évite d'avoir à traiter les null comme un cas spécial.Colonnes facultatives sur un système de rapports ou d'entrepôt de données. Pour cette situation, créez une ligne d'espace réservé pour "Non enregistré" dans la dimension et joignez-vous à cela. Cela simplifie les requêtes et fonctionne parfaitement avec les outils de création de rapports ad hoc.
Encore une fois, le livre de Celko est un bon traitement du sujet.
La meilleure chose à savoir sur les formulaires normaux est qu'ils sont des guides et que les guides ne doivent pas être obstinément respectés. Lorsque le monde universitaire entre en conflit avec le monde réel, il est rare de trouver de nombreux guerriers acédémiques survivants.
La réponse à cette question est que son ok pour utiliser des valeurs nulles. Évaluez simplement votre situation et décidez si vous souhaitez qu'ils apparaissent dans le tableau ou réduisez les données dans un autre tableau associé si vous pensez que le rapport des valeurs nulles aux valeurs réelles est trop élevé.
Comme un ami aime à dire: "Ne laissez pas le parfait être l'ennemi du bien". Pensez que Voltaire l'a également dit. 8)
Selon l'algèbre relationnelle stricte, les valeurs nulles ne sont pas nécessaires. Cependant, pour tout projet pratique, ils sont nécessaires.
Tout d'abord, de nombreuses données du monde réel sont inconnues ou non applicables et les valeurs nulles implémentent bien ce comportement. Deuxièmement, ils rendent les vues et les jointures externes beaucoup plus pratiques.
Vous constaterez qu'avec des systèmes d'acquisition de données étape par étape, vous ne pouvez pas éviter d'avoir des valeurs nulles dans une base de données car l'ordre de poser des questions/collecte de données correspond très rarement au modèle de données logique.
Ou vous pouvez par défaut les valeurs (nécessitant du code pour gérer ces valeurs par défaut). Vous pouvez supposer que toutes les chaînes sont vides au lieu de null, par exemple, dans votre modèle.
Ou vous pouvez disposer de tables de base de données intermédiaires pour l'acquisition de données qui se poursuivent jusqu'à ce que toutes les données soient obtenues avant de remplir les tables de base de données réelles. C'est beaucoup de travail supplémentaire.
Pour une base de données, null se traduit par "Je n'ai pas de valeur pour cela". Ce qui signifie que (fait intéressant), une colonne booléenne qui autorise les valeurs nulles est parfaitement acceptable et apparaît dans de nombreux schémas de base de données. En revanche, si vous avez un booléen dans votre code qui peut avoir une valeur `` vrai '', `` faux '' ou `` non défini '', vous risquez de voir votre code se retrouver sur thedailywtf tôt ou tard :)
Alors oui, si vous devez autoriser la possibilité qu'un champ n'ait aucune valeur, alors autoriser les valeurs nulles sur la colonne est parfaitement acceptable. C'est nettement mieux que les alternatives potentielles (chaînes vides, zéro, etc.)
Les valeurs nulles peuvent être difficiles à travailler, mais elles ont du sens dans certains cas.
Supposons que vous ayez un tableau de facturation avec une colonne "PaidDate" qui a une valeur de date. Que mettez-vous dans cette colonne avant le paiement de la facture (en supposant que vous ne savez pas à l'avance quand elle sera payée)? Ce ne peut pas être une chaîne vide, car ce n'est pas une date valide. Il n'est pas logique de lui donner une date arbitraire (par exemple 1/1/1900) car cette date n'est tout simplement pas correcte. Il semble que la seule valeur raisonnable soit NULL, car elle n'a pas de valeur.
Travailler avec des valeurs nulles dans une base de données présente quelques défis, mais les bases de données les gèrent bien. Les vrais problèmes sont lorsque vous chargez des valeurs nulles de votre base de données dans votre code d'application. C'est là que j'ai trouvé que les choses étaient plus difficiles. Par exemple, dans .NET, une date dans un ensemble de données fortement typé (imitant votre structure de base de données) est un type de valeur et ne peut pas être nulle. Vous devez donc créer des solutions de contournement.
Évitez les valeurs nulles lorsque vous le pouvez, mais ne les excluez pas car elles ont des utilisations valides.
Je suis d'accord avec de nombreuses réponses ci-dessus et je pense également que NULL peut être utilisé, le cas échéant, dans une conception de schéma normalisé - en particulier lorsque vous souhaitez éviter d'utiliser une sorte de "nombre magique" ou de valeur par défaut qui, à son tour, pourrait être trompeur!
En fin de compte, je pense que l'utilisation de null doit être bien pensée (plutôt que par défaut) pour éviter certaines des hypothèses énumérées dans les réponses ci-dessus, en particulier lorsque NULL pourrait être supposé être "rien" ou "vide", "inconnu" ou la "valeur n'a pas encore été entrée".
Je pense que vous confondez la modélisation des données conceptuelles avec la modélisation des données physiques.
Dans le CDM, si un objet a un champ facultatif, vous devez sous-taper l'objet et créer un nouvel objet lorsque ce champ n'est pas nul. Telle est la théorie dans les MDP
Dans le monde physique, nous faisons toutes sortes de compromis pour le monde réel. Dans le monde réel, les NULL sont plus que parfaits, ils sont essentiels
null signifie aucune valeur tandis que 0 ne le fait pas, si vous voyez un 0, vous ne connaissez pas la signification, si vous voyez un null, vous savez que c'est une valeur manquante
Je pense que les valeurs nulles sont beaucoup plus claires, 0 et '' prêtent à confusion car elles ne montrent pas clairement l'intention de la valeur stockée
Bien que les valeurs NULL soient techniquement acceptables comme valeur de champ, elles sont très souvent mal vues. Selon la façon dont les données sont écrites dans votre base de données, il est possible (et courant) de se retrouver avec une valeur de chaîne vide dans le champ par opposition à une valeur NULL. Ainsi, toute requête qui a ce champ dans le cadre de la clause WHERE, devra gérer les deux scénarios qui sont des frappes inutiles.
Mon opinion controversée pour la journée - le défaut d'autoriser les NULL dans les colonnes de la base de données était probablement la pire décision de conception universellement acceptée dans tous les terrains RDBM. Chaque fournisseur le fait, et c'est faux. Les valeurs NULL sont correctes dans certaines instances spécifiques et bien pensées, mais l'idée que vous devez explicitement interdire les valeurs NULL pour chaque colonne rend la nullité négligente plus courante qu'elle ne devrait l'être.
Techniquement, les valeurs nulles sont illégales dans les mathématiques relationnelles sur lesquelles la base de données relationnelle est basée. Donc, d'un point de vue du modèle relationnel purement technique et sémantique, non, ils ne vont pas bien.
Dans le monde réel, la dénormalisation et certaines violations du modèle sont acceptables. Mais, en général, les valeurs nulles sont un indicateur que vous devez examiner de plus près votre conception globale.
Je me méfie toujours des valeurs nulles et j'essaie de les normaliser chaque fois que je le peux. Mais cela ne signifie pas qu'ils ne sont pas toujours le meilleur choix. Mais je pencherais certainement du côté de "pas de null" à moins que vous ne soyez vraiment sûr que le fait d'avoir les null est meilleur dans votre base particulière.
Un piège si vous utilisez une base de données Oracle. Si vous enregistrez une chaîne vide dans une colonne de type CHAR, Oracle contraindra la valeur à NULL sans demander. Il peut donc être assez difficile d'éviter les valeurs NULL dans les colonnes de chaîne dans Oracle.
Si vous utilisez des valeurs NULL, apprenez à utiliser la commande SQL COALESCE, en particulier avec les valeurs de chaîne. Vous pouvez alors empêcher les valeurs NULL de se propager dans votre langage de programmation. Par exemple, imaginez une personne ayant un prénom, un prénom et un nom de famille mais vous souhaitez renvoyer un seul champ;
SELECT FullName = COALESCE(FirstName + ' ', '') + COALESCE(MiddleName+ ' ', '') + COALESCE(FamilyName, '') FROM Person
Si vous n'utilisez pas COALESCE, si la colonne any contient une valeur NULL que vous obtenez NULL retourné.
Ne prenez pas mes mots sarcastiques, je le pense. À moins que vous ne travailliez avec des bases de données de jouets, les valeurs NULL sont inévitables et dans le monde réel, nous ne pouvons pas éviter les valeurs NULL.
Juste pour dire comment pouvez-vous avoir un prénom, un deuxième prénom, un nom de famille pour chaque personne. (Le deuxième prénom et le nom de famille sont facultatifs, dans ce cas, les NULL sont là pour vous) et comment vous pouvez avoir Fax, Téléphone professionnel, Téléphone de bureau pour tout le monde dans la liste des blogs.
Les valeurs NULL sont correctes et vous devez les gérer correctement lors de la récupération. Dans SQL Server 2008, il existe un concept de colonnes éparses où vous pouvez également éviter l'espace pris pour les valeurs NULL.
Ne confondez pas NULL avec des zéros et toute autre valeur. Les gens disent que c'est juste.
Merci Naveen
Roches NULES. S'il n'était pas nécessaire dans certains cas, SQL n'aurait pas IS NULL et IS NOT NULL en tant qu'opérateurs spéciaux). NULL est la racine de la conceptuel universel, tout le reste n'est PAS NULL. Utilisez NULL librement, chaque fois qu'il est possible qu'une valeur de données soit absente mais ne soit pas manquée. Les valeurs par défaut ne peuvent compenser NULL que si elles sont absolument correctes tout le temps. Par exemple, si j'ai un champ à un seul bit "IsReady", il peut être parfaitement logique que ce champ ait une valeur par défaut false et NULL ne soit pas autorisé, mais cela affirme implicitement que nous savons que tout ce qui n'est pas prêt, alors qu'en fait nous n'avons peut-être pas de telles connaissances. Dans un scénario de workflow, il est probable que la personne qui décide prête ou non n'a pas encore eu la possibilité de donner son avis, donc un défaut de faux pourrait en fait être dangereux, les amenant à ignorer une décision qui semble avoir été prise mais qui n’a en fait été.
en aparté, et en référence à l'exemple de l'initiale du milieu, mon père n'avait pas de deuxième prénom, donc son initiale du milieu serait NULL - pas vide, espace ou astérisque - sauf dans l'armée où son initiale du milieu était NMI = Pas d'initiale du milieu. C'était idiot?
Personnellement, je pense que les valeurs nulles ne doivent être utilisées que lorsque vous utilisez le champ comme clé étrangère vers une autre table, pour symboliser que cet enregistrement ne se lie à rien dans l'autre table. À part cela, je trouve que les valeurs nulles sont en fait très gênantes lors de la programmation de la logique d'application. Puisqu'il n'y a pas de représentation directe d'une base de données nulle dans la plupart des langages de programmation pour de nombreux types de données, cela finit par créer beaucoup de code d'application pour gérer la signification de ces valeurs nulles. Lorsqu'une base de données rencontre un entier nul et essaie, par exemple, d'y ajouter une valeur de 1 (alias null + 1), la base de données renvoie null, car c'est ainsi que la logique est définie. Cependant, lorsqu'un langage de programmation essaie d'ajouter null et 1, il lève généralement une exception. Donc, votre code finit par être jonché de vérifications de ce qu'il faut faire lorsque la valeur est nulle, ce qui équivaut souvent à une conversion en 0 pour les nombres, une chaîne vide pour le texte et une date nulle (1900/1/1?) Pour les champs de date .
Je pense que la question se résume à ce que vous interprétez une valeur de NULL pour signifier. Oui, il existe de nombreuses interprétations pour une valeur NULL, mais certaines d'entre elles ne doivent jamais être utilisées. La vraie signification de NULL est déterminée par le contexte de votre application et ne doit jamais signifier plus d'une chose. Par exemple, une suggestion était que NULL sur un champ de date de naissance indiquerait que la personne était encore en vie. C'est dangereux.
En toute simplicité, définissez NULL et respectez-le. Je l'utilise pour signifier "la valeur dans ce domaine est inconnue pour le moment". Cela signifie cela et UNIQUEMENT cela. Si vous en avez besoin pour signifier autre chose, vous devez réexaminer votre modèle de données.
Il semble que si null est valide dans le contexte de l'attribut, alors il devrait être autorisé.
Mais que signifie null ? Voilà le hic. C'est "aucune valeur", mais il y a une douzaine de raisons différentes pour lesquelles il pourrait n'y avoir aucune valeur, et "null" ne vous donne aucune idée de ce que cela signifie dans ce cas. (Pas encore défini, pas applicable à cette instance, pas applicable à ce type, pas connu, pas connaissable, pas trouvé, erreur, bug du programme, ...)
Ceci est très courant dans Java où les références aux objets sont souvent nulles.
Il y a une école de pensée qui dit les références nulles y sont mauvaises aussi . Même problème: que signifie null ?
IIRC, Java a à la fois "null" et "uninitialized" (bien qu'il n'y ait pas de syntaxe pour ce dernier). Gosling a donc réalisé la folie d'utiliser "null" pour chaque type de "aucune valeur". Mais pourquoi arrêter avec seulement deux ?
C'est très bien avec null.
Tout se résume à la normalisation par rapport à la facilité d'utilisation et aux problèmes de performances.
Si vous vous en tenez aux règles de normalisation complètes, vous allez finir par écrire des trucs qui ressemblent à:
Sélectionnez c.id, c.lastname, ....... from customer c left join customerphonenumber cpn on c.id = cpn.customerid left join customeraddress ca on c.id = ca.customerid left join customerphonenumber2 cpn2 on c. id = cpn2.customerid etc, etc, etc