Mauvaise pratique Nullable Foreign Key?

Supposons que vous ayez une table Commandes avec une clé étrangère vers un ID client. Maintenant, supposons que vous souhaitiez ajouter une commande sans numéro de client (si cela devrait être possible est une autre question), vous devrez rendre la clé étrangère NULL ... Est-ce une mauvaise pratique ou préférez-vous travailler avec une table de liens entre Commandes et clients? Bien que la relation soit de 1 à n, une table de liens le ferait de n à n. Par contre, avec une table de liens, je n'ai plus ces NULLS ...

Il n'y aura en fait pas beaucoup de NULL dans la base de données, car un enregistrement avec une clé étrangère à NULL est juste temporairement jusqu'à ce qu'un client pour la commande soit ajouté.

(Dans mon cas, ce n'est pas une commande et un client).

EDIT: Qu'en est-il d'un client non affecté vers lequel établir un lien?

Avoir la table des liens est probablement une meilleure option. Au moins, il ne viole pas la normalisation BCNF (Boyce-Codd forme normale). cependant je préférerais être pragmatique. Si vous avez très peu de ces valeurs nulles et qu'elles ne sont que temporaires, je pense que vous devriez ignorer la table des liens car elle ne fait qu'ajouter de la complexité au schéma.

Sur une note latérale; l'utilisation d'une table de liens ne rend pas nécessairement n à n, si vous dans la table de liens utilisez la clé étrangère qui pointe vers votre table de commandes comme clé primaire dans cette table de liens, la relation est toujours 1..n. Il ne peut y avoir qu'une seule entrée dans cette table de liens par commande.

Non Il n'y a rien de mal avec les FK Nullable. Ceci est courant lorsque l'entité vers laquelle pointe le FK est dans une relation (zéro ou un) à (1 ou plusieurs) avec la table référencée par clé primaire.

Un exemple pourrait être si vous aviez à la fois une adresse physique et un attribut (colonne) d'adresse postale dans une table, avec des FK vers une table d'adresses. Vous pouvez rendre l'adresse physique NULL à gérer lorsque l'entité n'a qu'une boîte postale (adresse postale) et l'adresse postale Nullable à gérer lorsque l'adresse postale est la même que l'adresse physique (ou non).

Les colonnes Nullable peuvent être dans 1NF à 5NF, mais pas dans 6NF selon ce que j'ai lu.

Seulement si vous savez mieux que Chris Date "ce que signifie vraiment la première forme normale". Si x et y sont tous les deux nullables, et en effet dans certaines lignes x et y sont tous les deux null, alors WHERE x=yne donne pas true. Cela prouve au-delà de tout doute raisonnable que null n'est pas une valeur (car toute valeur réelle est toujours égale à elle-même). Et puisque le RM prescrit qu '"il doit y avoir une valeur dans chaque cellule d'une table", toute chose qui contient éventuellement des valeurs nulles n'est pas une chose relationnelle, et donc la question de 1NF ne se pose même pas.

J'ai entendu dire que les colonnes Nullable cassent en général le premier degré de normalisation.

Voir ci-dessus pour la bonne raison qui sous-tend cet argument.

Mais en pratique, c'est très pratique.

Seulement si vous êtes immunisé contre les maux de tête que cela provoque habituellement dans le reste du monde. Un de ces maux de tête (et ce n'est que mineur, comparativement à d'autres nullphénomènes) est le fait que WHERE x=ydans SQL signifie en fait WHERE x is not null and y is not null and x=y, mais que la plupart des programmeurs ne sont tout simplement pas conscients de ce fait et ne font que le lire. Parfois sans aucun mal, d'autres fois non.

En fait, les colonnes Nullable enfreignent l'une des règles de conception de base de données les plus fondamentales: ne combinez pas des éléments d'information distincts dans une colonne. Les valeurs nulles font exactement cela parce qu'elles combinent la valeur booléenne «ce champ est / n'est pas vraiment présent» avec la valeur réelle.

Je ne vois rien de mal à cela, il s'agit simplement d'une relation n-1 facultative qui sera représentée par un null dans la clé étrangère. Sinon, si vous mettez votre table de liens, vous devrez gérer qu'elle ne devienne pas une relation nn, ce qui causera encore plus de problèmes.

Des relations optionnelles sont certainement possibles dans le modèle relationnel.

Vous pouvez utiliser des valeurs nulles pour exprimer l'absence de relation. Ils sont pratiques, mais ils vous causeront les mêmes maux de tête que les nulls vous causent ailleurs. Les jointures sont un endroit où elles ne causent aucun problème. Les lignes qui ont une valeur null dans la clé étrangère ne correspondent à aucune ligne de la table référencée. Alors ils abandonnent une jointure intérieure. Si vous faites des jointures externes, vous allez quand même avoir affaire à des valeurs nulles.

Si vous voulez vraiment éviter les valeurs nulles (6ème forme normale), vous pouvez décomposer la table. L'une des deux tables décomposées a deux colonnes de clé étrangère. L'un est la clé étrangère facultative que vous possédez et l'autre est une clé étrangère référençant la clé primaire de la table d'origine. Maintenant, vous devez utiliser des contraintes pour empêcher la relation de devenir plusieurs-à-plusieurs, si vous voulez éviter cela.

L'utilisation de NULL serait un bon moyen de nettoyer les commandes incomplètes:

SELECT * FROM `orders`
WHERE `started_time` < (UNIX_TIMESTAMP() + 900) AND `customer_id` IS NULL

Ce qui précède afficherait les commandes de plus de 15 minutes sans identifiant client associé.

Si vous n'ajoutez la commande que temporairement sans identifiant client jusqu'à ce qu'un client soit défini, ne serait-il pas plus simple d'ajouter le client et la commande en une seule transaction, supprimant ainsi le besoin de l'entrée de clé étrangère NULL et évitant toute contrainte ou déclencheur vous avez configuré une violation?

Normalement, cette situation se produit dans les applications Web où la commande est détaillée avant que le client ne définisse qui il / elle est. Et dans ces situations, la commande est conservée dans l'état du serveur ou dans un cookie jusqu'à ce que tout l'état nécessaire à une commande complète soit fourni, moment auquel la commande est conservée dans la base de données.

Les clés étrangères NULL conviennent pour des choses comme les adresses, comme mentionné ci-dessus. Mais un champ client NULL n'a pas de sens pour une commande et doit être contraint.

Vous pouvez toujours ajouter une ligne artificielle à votre table Customer, quelque chose comme Id = -1 et CustomerName = 'Unknown', puis dans les cas où vous définiriez normalement votre CustomerId dans Order NULL, définissez-le sur -1.

Cela vous permet de ne pas avoir de FK nullable mais représente toujours le manque de données de manière appropriée (et vous évitera des utilisateurs en aval ne sachant pas comment gérer les NULL).

Les FK nulles pour les relations optionnelles plusieurs-à-un sont tout à fait correctes.

J'ai entendu dire que les colonnes Nullable en général cassent le premier degré de normalisation. Mais en pratique, c'est très pratique.

Oui, il y a quelque chose qui ne va pas. Ce n'est pas une clé étrangère si elle est nullable. Sa conception de base de données par code. Peut-être que vous faites un lien zéro vers unassigned. ou "Unassigned" si vous utilisez un caractère col. Gardez l'intégrité de vos données à 100%.