Valeurs NULL
Cela signifie également que l'article aura 5 identifiants, y compris le sien. Tout cela provoque des valeurs nulles (apparemment un gros non non, ce que je peux comprendre) car si le lieu et le prix sont facultatifs et ne sont pas utilisés sur une entrée de la table des éléments, j'aurai une valeur nulle là
Personnellement, je pense que c'est une situation où NULL les valeurs sont parfaites, et je n'aurais certainement aucun doute sur l'intégration de cela dans la conception de ma base de données.
Une façon dont j'ai vu d'autres réaliser la même chose sans NULL valeurs consiste à créer un enregistrement dans les tables facultatives (lieu et prix dans votre exemple) avec un ID de 0 qui signifie qu'il n'y a pas d'enregistrement associé - mais cela ne fait que 10 fois plus de travail pour le développeur de l'application pour filtrer ces enregistrements - il est BEAUCOUP plus facile de faire une jointure et si vous ne récupérez aucun enregistrement, il n'y a pas d'enregistrements associés dans la table facultative.
N'oubliez pas de faire un LEFT ou RIGHT OUTER join si vous voulez retourner Item s, qu'ils aient ou non un Place ou Price associé (vous obtiendrez NULL valeurs dans les colonnes de tableau facultatives pour Item s qui n'ont pas d'enregistrements associés) et un INNER rejoignez si vous seulement voulez l'Item c'est faire avoir un enregistrement facultatif associé.
Clés composites
Une clé composite est une clé dans une table composée de plusieurs colonnes. Si chacune de vos Person , Item , Place et Price ont tous un ID (même s'il ne s'agit que d'un nombre auto-incrémenté), vous n'aurez pas besoin d'une clé composite - juste une colonne de clé primaire dans chaque table et une colonne de clé étrangère dans le Item table pour chaque table liée - par ex. item_id , person_id , place_id , price_id . Vous indiquez que Item a son propre ID, vous ne devriez donc pas avoir besoin d'une clé composite - juste une clé primaire sur item_id colonne.
