Quelle est la meilleure conception de base de données pour cette situation?

Je travaille à la création d'une application métier pour mon entreprise et j'ai du mal à choisir la conception de base de données la plus appropriée pour une situation particulière. Disons que j'ai les entités suivantes:

Approbation

• Id
• Statut
• ...

ApprovalComment

• Id
• ApprovalId
• Commentaire

Ordre

• Id
• ...

Facture d'achat

• Id
• ...

Il peut évidemment y avoir plusieurs types d'approbations et plusieurs objets qui nécessitent des approbations. Quelle serait la plus appropriée des options suivantes pour concevoir les tableaux:

OPTION 1

Avoir une table d'approbations avec des clés étrangères nulles:

Approbations

• Id PK
• Statut
• OrderId FK NULL
• InvoiceId FK NULL

ApprobationComments

• Id PK
• ApprovalId FK
• Commentaire

Dans ce cas, je devrais ajouter une colonne pour chaque objet qui a besoin d'une approbation

OPTION 2

Avoir une table d'approbations parent avec des champs communs et une table enfant pour chaque objet qui a besoin d'une approbation:

Approbations

• Id PK
• Statut

ApprobationComments

• Id PK
• ApprovalId FK
• Commentaire

Approbations de commande

• ApprovalId PK FK
• OrderId FK

Approbation des factures

• ApprovalId PK FK
• InvoiceId FK

OPTION 3

Ayez une table d'approbations pour chaque objet:

Approbations de commande

• Id PK
• OrderId FK
• Statut

OrderApprovalComments

• Id PK
• OrderApprovalId FK
• Commentaire

Approbation des factures

• Id PK
• InvoiceId FK
• Statut

InvoiceApprovalComments

• Id PK
• InvoiceApprovalId FK
• Commentaire

Je sais que ce sont toutes des solutions valables, mais je ne peux pas décider laquelle serait la meilleure pour ajouter différents types d'approbations à l'avenir. Des pensées?

Une règle de base que j'utilise, c'est que c'est une mauvaise conception de base de données d'avoir à modifier une table pour accueillir un changement de code ou une nouvelle fonctionnalité si elle peut être planifiée à l'avenir.

Cela dit, j'utiliserais une variante de l'option 1

Approvals
    Id PK
    ApprovalTypeID FK
    Status


ApprovalComments
    ID PK
    ApprovalId FK
    Comment

ApprovalTypes
    ID PK
    Name

Désormais, lorsque vous ajoutez de nouveaux types d'objets qui nécessitent une approbation, il vous suffit d'insérer une ligne dans ApprovalTypes au lieu de modifier une table pour ajouter une colonne.

Cela dépend de la cardinalité de votre base de données et des éléments que vous souhaitez stocker, par exemple, vous pouvez simplement faire approbation_commentaire comme une relation unique et établir une relation 1-1 entre approbation et approbation_commentaire, vous allez donc ignorer créer une table supplémentaire ... I vu de cette façon:

Cardinality:
Approval N ---- 1 Approval_comment.
Approval 1 ----- N Order
Order N ----- 1 Invoice

Je vote pour la première alternative. Si vous ajoutez l'approbation requise à un élément, vous modifiez de manière appropriée le comportement de ces éléments, l'ajout d'une colonne n'est donc pas un gros problème. Et c'est également le meilleur moyen d'utiliser les jointures dans les requêtes.

Le second a des tableaux supplémentaires inutiles, ce qui peut suggérer que plus d'une approbation peut appartenir à un article.

Le troisième contient beaucoup de table redondante, et probablement du code redondant pour les gérer.

Si vous devez choisir entre l'une de vos trois options, je pense que l'option 2 est la meilleure. @sreimer a raison: le fait de devoir changer la structure de votre table pour les événements prévisibles indique une mauvaise conception. Avoir OrderID et InvoiceID dans le tableau des approbations est, à mon avis, très proche d'un groupe répétitif sur plusieurs colonnes et viole l'esprit, sinon la lettre, de la première forme normale.

J'envisagerais d'ajouter une colonne ApprovalID à chaque table nécessitant une approbation. Si la valeur est nulle, elle n'a pas été approuvée. Si ce n'est pas une option, je pense que @sreimer est sur la bonne conception - certaines clarifications pourraient aider à raffermir cela.

Je dirais que vous n'avez qu'une seule table =>

Approbation

id

statut

commentaire

Et avoir approbationId stocké dans inovice ou table de commande. De cette façon, vous n'avez pas à ajouter de colonne pour chaque objet et il y a moins de table à gérer. Et si je dois choisir entre l'option que vous avez fournie, j'irai avec l'option 2 et fusionnerai le commentaire d'approbation dans le tableau d'approbation.

Vous pouvez essayer quelque chose comme ceci:

Approbations
---------
  Identifiant
  statut
  nom_approbateur
  (d'autres choses)

Ordres
------
  Identifiant
  (d'autres choses)

Factures
--------
  Identifiant
  (d'autres choses)

objets_approuvés
----------------
  Identifiant
  Approval_id (FK - fait référence au tableau des approbations)
  approuvé_objet_id (FK - peut faire référence à l'ID des factures, commandes, etc ...)
  approuvé_objet_type_id (FK fait référence à approuvé_objet_types)

approuvé_objets_types
---------------------
  Identifiant
  Nom

Le approved_objectstableau vous indique quelle approbation va avec quel objet approuvé. L'objet approuvé pourrait être invoices, ordersou autre chose. Vous déterminez sur quelle table rechercher en fonction approved_object_type_id. Ce sera flexible, mais pourrait rendre les rapports un peu délicats.