Come si applicano i sottotipi in un database SQL Server?

Question

Sto lavorando a un programma in cui è possibile registrare i reclami. Esistono tre tipi di reclami: internal (errori dei dipendenti), external (errori di un'altra azienda) e supplier (errori commessi da un fornitore). Contengono dati diversi che non possono essere condivisi. Al momento ho 4 tavoli (reclamo, dipendente, azienda e fornitore). Ecco una visualizzazione delle tabelle:

Ho una conoscenza di base dei sottotipi ma non riesco a convertirli da un ERD in un vero database SQL Server, o almeno in questo scenario. Questo è più o meno come i 4 tavoli guardano (attributi irrilevanti omessi):

Reclamo
ComplaintId PK

dipendenti
EmployeeId PK
EmployeeName

impresa
CompanyID PK
CompanyName

Fornitore
IDFornitore PK
SupplierName

Quando si registra un reclamo, l'errore è fatto da uno dei 3 tipi e tutti memorizzare informazioni diverse. Qual è il modo migliore per memorizzare le informazioni in questo caso? Ho pensato di inserire 2 discriminatori nella tabella dei reclami: ComplaintType e Id in modo da poter indicare a quale tabella controllare e quale ID mi serve, ma non è molto pulito né efficiente.

Si prega di assistere.

Answer 1

Consiglio vivamente di NON utilizzare il metodo "2 discriminatori". Avrai effettivamente una colonna chiave esterna che punta a una delle tre tabelle, a seconda del campo ComplaintType. Se si esegue questa operazione, si bypassano i controlli di integrità referenziale forniti da SQL Server e tutti i vantaggi offerti dalle chiavi esterne. Al mio precedente lavoro, c'era una tabella chiamata EntityTypeIndexLabel che era una "tabella di bridge" che collegava IndexLabels (fondamentalmente metadati) a varie "entità", che erano molte diverse tabelle potenziali (Documento, Raccoglitore, Flusso di lavoro, ecc ...). Questo era semplicemente orribile. L'FK in questa tabella potrebbe indicare molte tabelle diverse. Record orfani potrebbero apparire ovunque. È necessario implementare una logica aggiuntiva per determinare su quale tabella partecipare. Le unire erano un dolore da scrivere in generale. C'erano tutti i tipi di mal di testa.

Credo che la vostra due opzioni sono:

-3 colonne nella denuncia: EmployeeComplaintID, CompanyComplaintID, SupplierComplaintID. I ComplaintID devono essere univoci in tutte le tabelle (si pensi ai GUID qui invece che alle colonne IDENTITY). Ogni riga in Complaint avrà solo uno di questi ID popolati, gli altri due saranno NULL. Quindi puoi semplicemente LEFT OUTER JOIN su queste tabelle in ogni query per ottenere i dati di cui hai bisogno.

-Una tavolo gigante con tutti i possibili campi necessari per ogni tipo di denuncia, i campi non utilizzati di altri tipi di reclamo a NULL.

Answer 2

Il problema principale è che occorre una sorta di "numero di serie" per identificare in modo univoco un reclamo indipendentemente dal tipo? Fondamentalmente, quindi, hai bisogno di una tabella per ogni tipo di reclamo (come avrai, credo), più la tabella principale "Reclamo" con il Reclamo. Ciascuna delle tabelle specifiche del tipo avrà una chiave esterna per Complaint.ComplaintId. Potresti trovare utile avere un campo "tipo" in Reclamo, ma ciò non è realmente necessario per il modello.

Answer 3

È possibile avere un reclamoSubTypeID con una relazione FK al PK di tutte e tre le tabelle del sottotipo (dipendente, azienda e fornitore).

Answer 4

vedere alcune davvero buone risorse sul tema:

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

C'è fondamentalmente tre approcci ben noti:

• tabella per sottoclasse
• tabella per ogni Gerarchia
• tabella per ogni tipo concreto

Ognuno ha vantaggi e svantaggi, brilla in qualche situazione e succhia in altri - studiare le risorse e vedere quale dei tre adatta alle vostre esigenze il migliore.

Answer 5

In risposta alla prenotazione Sei commento alla risposta accettata:

Qui di seguito è un modo per avere un controllo di controllo per assicurare che solo uno dei tre tasti dispone di dati:

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 
    );