Choisir l'emplacement d'une clé étrangère entre deux tables?

Question

J'ai une table de bon de commande et une autre table pour contenir les articles dans un ordre d'achat particulier pour les médicaments.

Exemple:

PO_Table (POId, MainPharmacyID, SupplierID, PreparedBy) 
PO_Items_Table (POItemID, ...) 

J'ai deux options de choix qui table pour créer un lien vers qui et ils semblent tous les deux valides. Je l'ai fait un certain nombre de fois et l'ai fait de toute façon.

• J'aimerais savoir s'il existe des règles à l'endroit où attacher un étranger?
• Dans ma situation où dois-je attacher ma clé étrangère?

Mise à jour:

Mes deux options mettent POItemID dans le PO_Table ou de mettre poid dans le PO_Items_Table.

Mise à jour 2:

En supposant que la relation entre les deux tables est un-à-un

Answer 1

Il suffit de faire pointer vers la PRIMARY KEY de la table référencée:

PO_Table (POId PRIMARY KEY, MainPharmacyID, SupplierID, PreparedBy) 
PO_Items_Table (POItemID, POId FOREIGN KEY REFERENCES PO_Table (POId), ...) 

En fait, dans votre PO_Table je ne vois aucune autre clé candidate sauf POId, alors que pour l'instant cela semble être la seule solution disponible pour moi.

Quelles sont les «deux options» que vous envisagez?

Mise à jour:

Mettre POItemID dans le PO_Table n'est pas une option à moins que vous voulez que vos ordres pour plus d'un élément en eux.

Il suffit de regarder à l'intérieur: si vous avez une seule colonne qui stocke le id de l'article commandé dans le tableau de commande, où allez-vous stocker les autres articles?

Mise à jour 2:

S'il y a un-à-un, normalement vous fusionnez uniquement les tables: combiner tous les champs des deux tables en un seul enregistrement.

Cependant, il existe des cas où vous devez diviser les tables. Dites, l'une des entités est rarement définie mais comporte trop de champs.

Dans ce cas, vous créez une relation distincte pour la deuxième entité et définissez sa colonne PRIMARY KEY comme FOREIGN KEY.

Imaginons un modèle qui décrit les serrures et les clés et les clés ne peuvent pas être dupliqués (si un verrou correspond au plus une clé et vice versa):

Pairs (PairID PRIMARY KEY, LockID UNIQUE, LockProductionDate, KeyId UNIQUE, KeyProductionDate) 

S'il n'y a pas de clé pour une verrouiller ou pas de verrou pour une clé, nous avons juste mis NULLS dans les champs correspondants.

Cependant, si toutes les clés ont un verrou, mais seulement quelques serrures ont des clés, nous pouvons diviser la table:

Locks (LockID PRIMARY KEY, LockProductionDate, KeyID UNIQUE) 
Keys (KeyID PRIMARY KEY, KeyProductionDate, FOREIGN KEY (KeyID) REFERENCES Locks (KeyID)) 

Comme vous pouvez le voir, le KeyID est à la fois un PRIMARY KEY et un FOREIGN KEY dans le tableau Keys .

Vous pouvez lire cet article dans mon blog:

• What is entity-relationship model?

, qui décrit certaines façons de cartographier le modèle ER (entités et relations) dans le modèle relationnel (tables et clés étrangères

Answer 2

Vous n'avez pas deux options. Une contrainte de clé étrangère doit être attachée à la table (et à la colonne) qui contient la clé étrangère. Et il doit référencer (ou pointer vers) la clé primaire dans l'autre table. Je ne comprends pas très bien ce que tu veux dire quand tu dis que tu l'as fait un certain nombre de fois de toute façon ... Quelle autre façon?

Answer 3

Il ressemble à votre PO_Table est le parent logique du PO_Items_Table, ce qui signifie que la clé primaire du PO_Table devrait être utilisé comme clé étrangère dans la table des articles

Answer 4

Si PO signifie « bons de commande » et PO L'élément correspond à un seul élément de campagne d'un ordre d'achat, vous n'avez alors qu'un seul choix concernant la configuration des clés étrangères. Il peut y avoir plusieurs articles pour chaque commande, mais il n'y aura qu'un seul bon de commande pour chaque article. Dans ce cas, Quassnoi a donné le bon design. En tant que voyant latéral, chaque fois que j'ai créé une base de données de commandes, j'ai créé une table primaire composée de POID et d'ItemID. Mais ItemID n'est pas unique parmi tous les éléments, seulement les éléments qui appartiennent à un seul PO. Chaque fois que je commence un nouveau PO, je recommence avec ItemID égal à un. Cela me permet de reconstruire un bon de commande plus tard, et d'obtenir les articles dans le même ordre que lors de la création de la commande. C'est un sujet trivial pour la plupart des traitements de données, mais il peut rendre les clients fou s'ils regardent un PO plus tard, et les éléments sont hors séquence, car ils perçoivent la séquence.