tables - set foreign key mysql




Base de données: quel design pointer sur deux possibilités? (2)

Je suis en train de concevoir un datamodèle pour un nouveau projet.

L'une des exigences spécifie que certains objets peuvent désigner une personne ou une entreprise.

Quel est le moyen le plus intelligent d'y parvenir?

J'ai pensé à un lien de table "acteur" comme celui-ci (dessiné avec l'excellent yUML.me BTW):

Dans la table des actor , selon actor_type , person_id ou company_id est une clé étrangère sur sa table correspondante ou est NULL . De cette façon, lorsque one_table veut récupérer des détails sur l' actor , je commence par vérifier le champ actor_type et récupérer soit person_id soit company_id .

Cela fonctionne, mais je cherche un meilleur design. Voici le lien pour éditer le diagramme


C'est un cas classique de classes / sous-classes (ou, si vous préférez les types / sous-types). Je vous suggère de visiter les trois balises suivantes et de regarder à la fois les questions marquées et le wiki des tags que vous pouvez voir sous "learn more".

héritage -table unique classe -héritage -table partagée-clé-clé

Cela peut vous donner toutes les réponses dont vous avez besoin. Ou vous pouvez préférer ajouter un ou plusieurs de ces tags à votre question, afin d'attirer plus de réponses.

Remarque: la raison pour laquelle le mot "héritage" est utilisé dans les balises est que ces techniques vous permettent d'obtenir certains des avantages qui sont intégrés dans les environnements d'objets qui implémentent l'héritage.


Il est difficile de vraiment donner une réponse à cela, mais j'aurais quelques notes qui pourraient vous être utiles.

Mais ce ne sont que quelques notes.

Globalement, ce modèle de données semble bien compte tenu de ce qui est connu.

  • Le type d'acteur ne doit pas nécessairement être une autre table. Il pourrait s'agir simplement d'une valeur codée sur cette table par exemple.
  • Comme indiqué dans d'autres commentaires, la table de type acteur n'est pas techniquement nécessaire si l'acteur ne peut que pointer vers les deux choses - mais je l'utiliserai probablement car il est plus facile à maintenir et plus lisible à long terme pour les futurs responsables de le code / sql / base de données. c'est-à-dire que la présence du champ pour indiquer le type ajoute de la valeur à la lisibilité humaine du code / sql et du modèle même si la machine n'en a pas besoin.
  • En pensant à l'évolution de la base de données, une chose à considérer, pensez-vous que ce sera toujours une personne / entreprise ou peut-être qu'il y aura des types différents à l'avenir. S'il est probable qu'il s'agisse de types d'acteurs supplémentaires dans le futur, il est utile de considérer maintenant si factoriser actor_type et id dans une table de liens peut être utile pour limiter l'évolution du schéma pour cette table.




foreign-keys