Référence multiple dans SQL

Question

Je travaille sur une base de données mais je suis un peu nouveau à ce sujet, donc j'ai rencontré un problème aujourd'hui. J'ai quelques tables: BUREAU, SALLE, EMPLOYÉ et DOCUMENT. Le document doit spécifier l'expéditeur, qui peut être un employé unique, une pièce entière ou un bureau entier, de sorte qu'il doit avoir une référence aux clés primaires de ces tables. Est-ce que je devrais faire une table "parallèle" pour le manipuler (par exemple j'ai fait un pour manipuler les documents de plusieurs destinataires) ou il y a une autre manière? Merci

Answer 1

Je serais enclin à avoir une clé étrangère à chacune des trois tables avec une contrainte de vérification qui assure qu'un seul aura une valeur. De cette façon, vous pouvez toujours utiliser l'intégrité référentielle standard. Btw, cela suppose que la règle métier est que chaque document doit avoir un et un seul expéditeur.

Create Table Document 
(
    SenderEmployeeId ... 
    , SenderRoomId ... 
    , SenderOfficeId.... 
    , Constraint CK_Document_SingleSender Check (Case 
                When SenderEmployeeId Is Not Null And SenderRoomId Is Null And SenderOfficeId Is Null Then 1 
                When SenderRoomId Is Not Null And SenderEmployeeId Is Null And SenderOfficeId Is Null Then 1 
                When SenderOfficeId Is Not Null And SenderEmployeeId Is Null And SenderRoomId Is Null Then 1 
                Else 0 
                End = 1) 
)

Answer 2

Vous essayez de créer des clés étrangères conditionnelles que vous ne pouvez pas faire dans SQL Server. Je pense que la création d'une table pour contenir le document et l'expéditeur est une bonne idée, mais vous ne serez pas en mesure de créer les clés étrangères. Vous pouvez cependant implémenter un Check Constraint pour contrôler les données.

Answer 3

Je voudrais implémenter cela avec des tables parallèles comme vous l'avez mentionné. Les tables seraient en tant que tels:

OfficeDocuments (OfficeID, DocumentID)

RoomDocuments (RoomID, DocumentID)

EmployeeDocuments (EmployeeID, DocumentID)

Vous pouvez concevoir des requêtes plus flexibles avec un design comme ceci, comme joinin contre les tables de pièce et de bureau pour acquérir une liste d'employés.

La méthode que vous choisissez doit dépendre de la flexibilité dont vous avez besoin. Si vous ne concevez qu'une ou deux requêtes pour cette table, il peut être judicieux d'avoir une table dénormalisée à la place (en utilisant des contraintes de vérification et plusieurs attributs pour chaque type de table pouvant être un expéditeur).