Due tabelle con struttura simile e integrità referenziale o una tabella

Question

Due tabelle con struttura simile e integrità referenziale o una tabella

#1 da (2 voti)

3

Panoramica

La mia domanda ruota intorno al bilanciamento del database e della semplicità del codice utilizzando 2 opzioni per progettare attorno al seguente requisito.

Fatti di sfondo

Il DB: SQL Server
Il codice: ASP.NET MVC C # utilizzando EntityFramework

Ho una tabella, AllocationNeed (vedi sotto).

/****** Object:  Table [dbo].[AllocationNeed]    Script Date: 10/7/2015 12:39:43 PM ******/
CREATE TABLE [dbo].[AllocationNeed](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [FacilityId] [int] NOT NULL,
    [WorkReleaseHeaderId] [int] NULL,
    [NeedSourceId] [int] NOT NULL,
    [NeedSourceType] [nvarchar](50) NOT NULL,
    [ItemId] [int] NOT NULL,
    [QtyNeeded] [decimal](18, 4) NOT NULL,
    [CreatedById] [int] NOT NULL,
    [CreatedOn] [datetime] NOT NULL,
    [ModifiedById] [int] NOT NULL,
    [ModifiedOn] [datetime] NOT NULL

Esistono almeno 2 fonti di esigenze di inventario e oggi sto utilizzando NeedSourceType e NeedSourceId per conservare tali informazioni in questa singola tabella.

In questo caso un NeedSourceType è un "ordine di spedizione" e un "ordine di lavoro". Entrambi sono rappresentati in altre tabelle rispettivamente come OrderHeader e WorkOrderHeader. NeedSourceId è i rispettivi valori di chiave esterna di OrderHeader.Id o WorkOrderHeader.Id.

C'è anche una tabella figlio correlata (da molti a 1 AllocationNeed) AllocatedContainers, che ha una chiave esterna indietro a AllocationNeed.Id. Nel prossimo futuro, questa tabella potrebbe avere lo stesso problema in quanto dovremo aggiungere il concetto di AllocatedLocations oltre a AllocatedContainers, quindi, di nuovo, potremmo avere due o più tabelle.

Opzioni di approccio Pro e contro

Approccio: una tabella

Pro:

il mio codice è un po 'più pulito in quanto di solito ho bisogno di eseguire aggregati sul fabbisogno totale combinato, quindi non c'è bisogno di fare un join se questi erano due tabelle
Il codice è più semplice per scrivere e leggere su questa tabella anziché su 2 o più tabelle
non aggiunge tabelle aggiuntive a DB

Contro:

Spesso ho bisogno di ottenere attributi degli ordini di spedizione e di lavoro associati, quindi devo eseguire join nel mio codice invece di accedere a AllocationNeed.OrderHeader.ShipDate
Non esiste integrità referenziale
Impossibile utilizzare le eliminazioni a cascata in modo che il codice sia più complesso da eliminare record.

Approccio: due tabelle

Sostanzialmente i pro e i contro opposti all'approccio a una tabella.

Alla ricerca di pensieri o suggerimenti su questo dilemma di design.

database-design relational-database entity-framework

posta Chad Richardson 07.10.2015 - 21:07

fonte

1 risposta

Leggi altre domande sui tag database-design relational-database entity-framework

Migrazioni di Django: lega i dati al codice? Qualsiasi motivo per continuare a utilizzare stringhe semplici in ES2015?

score 2 · Accepted Answer

Nelle tue tabelle principali su cui aggiungi / rimuovi record, fai sempre le cose nella perfetta tradizione relazionale. "L'integrità referenziale non è applicabile" significa "non è relazionale" e "non è relazionale" dovrebbe sempre significare automaticamente "inaccettabile". Se non lo fai in questo modo, prima o poi te ne pentirai amaramente.

Il tipo di o-relationship che stai cercando di modellare è il migliore (più relazionalmente) descritto con più chiavi esterne, (nel tuo caso due,) di cui esattamente uno sarà non nullo in una data riga. Pertanto, se comprendo correttamente lo scenario, perderesti le colonne NeedSourceType e NeedSourceId e le sostituirai con ShipOrderId e WorkOrderId .

Se hai bisogno di avere una vista più semplice, di sola lettura, (come per l'esecuzione di aggregati sullo spazio pubblicitario combinato totale), crea viste del database che sono fondamentalmente pseudo-tabelle definite come query.

Se hai esigenze di data mining più pesanti, crea ulteriori serie di tabelle che contengono le stesse informazioni ma in una forma denormalizzata (non strettamente relazionale) per facilitare le query. Ma queste tabelle dovrebbero essere utilizzate solo per le query, mai per l'aggiornamento e l'eliminazione.