Dev Faq
7
votes

Table commune à plusieurs entités pour plusieurs entités

Supposons que j'ai deux tables, client et vendeur. Je veux avoir une table d'adresses commune pour les adresses de clients et de fournisseurs. Les clients et les fournisseurs peuvent tous deux en avoir une à de nombreuses adresses.

Option 1

Ajouter des colonnes pour l'adresseDID au Client et Vendeur Tables. Cela ne semble tout simplement pas comme une solution propre pour moi. xxx

option 2

déplacez la clé étrangère sur l'adresse table. Pour un client, adresse.customéride sera peuplé. Pour un fournisseur, adresse.vendorid sera peuplé. Je n'aime pas cela non plus - je ne devrais pas avoir besoin de modifier la table d'adresses à chaque fois que je souhaite l'utiliser pour une autre entité. xxx

option 3

J'ai aussi vu cela - une seule colonne de clé étrangère sur la table d'adresses avec une autre colonne pour identifier quelle table à clé étrangère appartient à l'adresse. Je n'aime pas celui-ci car il nécessite que toutes les tables de clé étrangère ont le même type d'identifiant. Il semble aussi désordonnée une fois que vous commencez à coder contre elle. xxx

donc, suis-je trop difficile, ou y a-t-il quelque chose que je n'ai pas pensé? < / p>

0 commentaires

4 Réponses :

7
votes

Je pense que les trois options que vous avez données, je serais le plus enclin à aller avec option 1. Normalement, un client ou un fournisseur n'aura pas plus de quelques adresses différentes, mais si elles le font, peut-être la solution ci-dessous travaillerait mieux pour vous. Je n'irais pas pour l'option 2, car il n'a probablement pas de sens d'associer une adresse avec un client et un fournisseur en même temps. Je sais que vous ne seriez probablement que définir un de ces identifiants à la fois, mais le modèle pourrait être déroutant, et vous devrez peut-être ajouter une logique spéciale pour vous assurer que seul le CustomerID ou le Vendorid est défini sur un enregistrement donné. Je ne ferais certainement pas l'option 3, car vous ne pouvez pas faire de FKID un vrai FK. Si vous souhaitez que une colonne référendra plus d'une table, vous ne pourrez pas utiliser une contrainte FK dans la base de données pour l'appliquer. De plus, si vous envisagez d'utiliser un orj pour interagir avec la base de données dans le code, ils ont tendance à avoir du mal à traiter avec des touches étrangères "FAIN" qui font référence à plusieurs tables en fonction d'une colonne "discriminator" distincte.

Si vous voulez vraiment Solution ouverte, vous pouvez créer de nombreuses relations entre les clients et l'adresse et le fournisseur et l'adresse. P> 

Customer
--------
CustomerID (PK)

Vendor
------
VendorID (PK)

Address
-------
AddressID (PK)

CustomerAddress
---------------
CustomerID (FK/PK)
AddressID (FK/PK)

VendorAddress
-------------
VendorID (FK/PK)
AddressID (FK/PK)

0 commentaires
0
votes

Pouvez-vous redéfinir la table pour avoir les champs suivants: xxx

ou vous pouvez avoir deux tables:

  • Tableau d'adresse, où aucune référence aux types d'adresse. c'est-à-dire avoir les deux
    • ID d'entité (clé)
    • adresse
    • Table de type d'adresse, où il pointerait une entrée à l'entrée et un drapeau à l'extérieur de la table pour avoir:
      • ID d'entité (ID FK à entité dans le tableau ci-dessus)
      • Type d'entité (client ou fournisseur)
2 commentaires

C'est mon option 3. Vous l'avez mieux expliqué que moi. Je veux toujours l'éviter.

Le codage peut être simplifié si vous utilisez le drapeau du type d'adresse comme filtre. Et vous pouvez assurer l'unicité à l'aide de la clé d'agrégat sur le drapeau et l'identifiant. Mais si vous essayez de trouver une quatrième solution, trouvez la réponse modifiée ci-dessus

8
votes

Je dirais que la pièce manquante du puzzle est la relation "est une" relation qui est souvent négligée dans la modélisation des données; Ceci est distinct de la relation familière "a une" relation. Une relation "est une" relation est similaire à une relation d'héritage dans une conception orientée objet. Pour modéliser cela, vous aurez besoin d'une table de base représentant les attributs communs des fournisseurs et des clients. Par exemple, nous pourrions appeler la table de base "Organisations": 

Organizations       Vendors               Customers
--------------      ---------------------  ---------------------
OrganizationID(PK)  OrganizationID(FK/PK)  OrganizationID(FK/PK)
AddressID1(FK)
AddressID2(FK)

1 commentaires

+1 pour l'analogie OO. J'ai continué à penser que c'est un problème de héritage très simple dans OO, mais je ne savais pas comment le modeler dans un modèle de données. Je pense que je peux combiner votre solution avec Andy White et proposer la relation unique à laquelle je cherche.

2
votes

Que diriez-vous d'avoir quatre tables avec une porte d'entrée aux adresses? Donc, vous auriez 

Customer
    customerId (PK)
    addressBookId (FK to AddressBook)

Vendor
    vendorId (PK)
    addressBokId (FK to AddressBook)

AddressBook
    addressBookId (PK)

Address
    addressId (PK)
    addressBookId (FK to AddressBook)

0 commentaires

Articles qui pourrait vous intéresser :

Problème de jointure sql, impossible de récupérer les enregistrements de la table a qui correspondent à une condition de la table b et les enregistrements restants de la table a
Comment puis-je obtenir les clés primaires à partir de tables logiques dans DB2?
Le code VB.Net pour sauvegarder et enregistrer la base de données SQL Server ne fonctionnera pas
Comment supprimer des enregistrements spécifiques d'une table dans Visual Studio?