Qual è il miglior design di database per questa situazione?

Sto lavorando alla creazione di un'applicazione aziendale per la mia azienda e faccio fatica a scegliere il design di database più appropriato per una situazione particolare. Diciamo che ho le seguenti entità:

Approvazione

• Id
• Stato
• ...

ApprovalComment

• Id
• ApprovalId
• Commento

Ordine

• Id
• ...

Fattura

• Id
• ...

Ovviamente potrebbero esserci più tipi di approvazioni e più oggetti che richiedono approvazioni. Quale sarebbe la più appropriata delle seguenti opzioni per progettare le tabelle:

OPZIONE 1

Avere una tabella di approvazioni con chiavi esterne nulle:

approvazioni

• Id PK
• Stato
• OrderId FK NULL
• InvoiceId FK NULL

ApprovalComments

• Id PK
• Approvazione ID FK
• Commento

In questo caso dovrei aggiungere una colonna per ogni oggetto che necessita di un'approvazione

OPZIONE 2

Avere una tabella Approvazioni padre con campi comuni e una tabella figlio per ogni oggetto che necessita di un'approvazione:

approvazioni

• Id PK
• Stato

ApprovalComments

• Id PK
• Approvazione ID FK
• Commento

OrderApprovals

• Approvazione ID PK FK
• OrderId FK

InvoiceApprovals

• Approvazione ID PK FK
• InvoiceId FK

OPZIONE 3

Avere una tabella di approvazioni per ogni oggetto:

OrderApprovals

• Id PK
• OrderId FK
• Stato

OrderApprovalComments

• Id PK
• OrderApprovalId FK
• Commento

InvoiceApprovals

• Id PK
• InvoiceId FK
• Stato

InvoiceApprovalComments

• Id PK
• InvoiceApprovalId FK
• Commento

So che sono tutte soluzioni valide, ma non riesco a decidere quale sarebbe la migliore per l'aggiunta di diversi tipi di approvazioni in futuro. qualche idea?

Una regola empirica che uso è che è una cattiva progettazione del database dover modificare una tabella per adattarsi a una modifica del codice o a una nuova funzionalità se può essere pianificata per il futuro.

Detto questo, vorrei usare una variante dell'Opzione 1

Approvals
    Id PK
    ApprovalTypeID FK
    Status


ApprovalComments
    ID PK
    ApprovalId FK
    Comment

ApprovalTypes
    ID PK
    Name

Ora, quando si aggiungono nuovi tipi di oggetti che richiedono l'approvazione, è sufficiente inserire una riga in ApprovalTypes invece di modificare una tabella per aggiungere una colonna.

Dipende dalla cardinalità del tuo DB e dalle cose che vuoi archiviare, ad esempio potresti semplicemente rendere Approvation_comment come univoco e creare una relazione 1-1 tra Approvation e Approvation_comment, quindi salterai a creare una tabella aggiuntiva ... I visto in questo modo:

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

Voto per la prima alternativa. Se aggiungi un requisito di approvazione a un articolo, modifichi in modo propizio il comportamento di tali articoli, quindi aggiungere una colonna non è un grosso problema. Inoltre, è il modo migliore per utilizzare i join nelle query.

Il secondo ha inutili tabelle aggiuntive, che potrebbero suggerire che più di un'approvazione possa appartenere a un elemento.

Il terzo contiene molte tabelle ridondanti e probabilmente codice ridondante per gestirle.

Se devi decidere tra una delle tue tre opzioni, credo che l'opzione 2 sia la migliore. @sreimer ha ragione a dire che dover modificare la struttura della tabella per punti eventi prevedibili con un design errato. Avere OrderID e InvoiceID nella tabella Approvations è, a mio modo di vedere, molto vicino a un gruppo che si ripete tra le colonne e viola lo spirito, se non la lettera, della prima forma normale.

Vorrei prendere in considerazione l'aggiunta di una colonna ApprovalID a ogni tabella che necessita di approvazione. Se il valore è null, non è stato approvato. Se questa non è un'opzione, penso che @sreimer sia sulla progettazione corretta - alcuni chiarimenti potrebbero aiutare a risolverlo.

Vorrei suggerire che hai solo una tabella =>

Approvazione

id

stato

commento

E avere l'approvazioneId archiviato nella tabella degli ordini o degli ordini. In questo modo non è necessario aggiungere colonne per ogni oggetto e ci sono meno tabelle da mantenere. E se devo scegliere tra l'opzione che hai fornito, andrò con l'opzione 2 e unirò il commento di approvazione nella tabella di approvazione.

Potresti provare qualcosa del genere:

approvazioni
---------
  ID
  stato
  approver_name
  (altre cose)

Ordini
------
  ID
  (altre cose)

Fatture
--------
  ID
  (altre cose)

approved_objects
----------------
  ID
  Approval_id (FK - si riferisce alla tabella delle approvazioni)
  approvato_oggetto_id (FK - può fare riferimento all'ID di fatture, ordini, ecc ...)
  certified_object_type_id (FK si riferisce a approvato_object_types)

approved_object_types
---------------------
  ID
  Nome

La approved_objectstabella indica quale approvazione corrisponde a quale oggetto approvato. L'oggetto potrebbe essere approvato in invoices, orderso qualcos'altro. Si determina in quale tabella cercare in base approved_object_type_id. Questo sarà flessibile, ma potrebbe rendere un po 'difficile la segnalazione.