Comment appliquer des sous-types dans une base de données SQL Server?

Question

Je travaille sur un programme dans lequel vous pouvez enregistrer des plaintes. Il existe trois types de plaintes: internal (erreurs des employés), external (erreurs d'une autre société) et supplier (erreurs commises par un fournisseur). Ils contiennent des données différentes qui ne peuvent pas être partagées. J'ai actuellement 4 tables (plainte, employé, compagnie et fournisseur). Voici une visualisation des tables:

J'ai une compréhension de base des sous-types, mais je ne peux pas les traduire à partir d'une ERD dans une base de données SQL Server réelle, ou du moins dans ce scénario. Ceci est à peu près comment les 4 tables regardent (attributs non pertinents omis):

plainte
ComplaintId PK

employé
EmployeeId PK
EmployeeName

Société
COMPANYID PK
CompanyName

Fournisseur
PK SupplierID
NomFournisseur

Lors de l'enregistrement d'une plainte, l'erreur est faite par l'une des 3 types et ils ont tous autre magasin d'informations. Quel est le meilleur moyen de stocker des informations dans ce cas? J'ai pensé à mettre 2 discriminateurs dans la table de plainte: ComplaintType et Id afin que je puisse pointer vers quelle table vérifier et quel ID j'ai besoin, mais ce n'est pas très propre et efficace.

Veuillez nous aider.

Answer 1

Je vous recommande fortement de NE PAS utiliser la méthode "2 discriminateurs". Vous aurez effectivement une colonne de clé étrangère qui pointe vers l'une des trois tables, en fonction du champ ComplaintType. Si vous faites cela, vous contournerez les vérifications d'intégrité référentielle fournies par SQL Server et tous les avantages associés aux clés étrangères. Lors de mon précédent travail, il y avait une table appelée EntityTypeIndexLabel qui était une table de pont reliant IndexLabels (essentiellement des métadonnées) à diverses «entités», qui étaient de nombreuses tables potentielles différentes (Document, Binder, Workflow, etc ...). C'était tout simplement horrible. Le FK dans cette table pourrait pointer vers de nombreuses tables différentes. Les enregistrements orphelins peuvent apparaître partout. Une logique supplémentaire a dû être implémentée pour déterminer à quelle table se connecter. Les jointures étaient une douleur à écrire en général. C'était toutes sortes de maux de tête.

Je pense que vos deux options sont:

-3 colonnes dans la plainte: EmployeeComplaintID, CompanyComplaintID, SupplierComplaintID. ComplaintIDs doit être unique dans toutes les tables (pensez aux GUID ici au lieu des colonnes IDENTITY). Chaque rangée dans Complaint aura un seul de ces IDs rempli, les deux autres seront NULL. Ensuite, vous pouvez simplement quitter LEFT OUTER JOIN sur ces tables dans chaque requête pour obtenir les données dont vous avez besoin.

-Un tableau géant avec tous les champs possibles dont vous avez besoin pour chaque type de réclamation, définissant les champs non utilisés des autres types de réclamations sur NULL.

Answer 2

Est-ce que le principal problème est que vous avez besoin d'une sorte de "numéro de série" pour identifier de manière unique une plainte quel que soit le type? Fondamentalement, alors, vous avez besoin d'un tableau pour chaque type de plainte (comme vous l'aurez, je pense), plus le tableau principal "Plainte" avec le ComplaintId. Chacune des tables spécifiques au type aura une clé étrangère à Complaint.ComplaintId. Vous pouvez trouver utile d'avoir un champ "type" dans Plainte, mais ce n'est pas vraiment nécessaire pour le modèle.

Answer 3

Vous pouvez avoir un type de dépôt de plainte avec une relation FK avec le PK des trois tables de vos sous-types - employé, entreprise et fournisseur.

Answer 4

Voir quelques vraiment bonnes ressources sur le sujet:

• Implementing table inheritance in SQL Server
• How to model inheritance in a database
• How do you effectively model inheritance in a database?

Il y a essentiellement trois approches bien connues:

• table par classe
• Tableau par hiérarchie
• Tableau par type béton

Chacun a des avantages et des inconvénients, resplendit dans une situation et succions dans d'autres - étudier les ressources et voir lequel des trois adapté à vos besoins le meilleur.

Answer 5

En réponse à toi sont commentaires sur la réponse acceptée:

Voici une façon d'avoir un chèque de contrôle pour assurer que l'une des trois touches comporte des données:

alter table complaint_master 
    add constraint loc_attribute_has_one_value 
    check ( 
     (case when complaint_employee is null then 0 else 1 end) + 
     (case when complaint_supplier is null then 0 else 1 end) + 
     (case when complaint_external is null then 0 else 1 end) = 1 
    );