Questi stili di progettazione del database (o anti-pattern) hanno nomi?

Question

Considera un database con tabelle Prodotti e Dipendenti. Esiste un nuovo requisito per modellare i product manager attuali, essendo l'unico dipendente responsabile di un prodotto, osservando che alcuni prodotti sono abbastanza semplici o abbastanza maturi da non richiedere un product manager. Cioè, ogni prodotto può avere zero o un product manager.

Approccio 1: alter table Product per aggiungere un nuovo NULL grado colonna product_manager_employee_ID modo che un prodotto con nessun manager prodotto è modellato dal valore NULL.

Approccio 2: creare una nuova tabella ProductManagers con non NULL colonne grado product_ID e employee_ID, con un vincolo univoco product_ID, in modo che un prodotto con nessun manager prodotto è modellato dall'assenza di una riga in questa tabella.

Ci sono altri approcci ma questi sono i due che mi sembra di incontrare più spesso.

presupponendo che siano entrambe le scelte progettuali legittime (come io sono propenso a credere) e si limita a rappresentare diversi stili, non hanno nomi? Preferisco l'approccio 2 e trovo difficile trasmettere la differenza di stile a qualcuno che preferisce l'approccio 1 senza impiegare un esempio reale (come ho fatto qui!) Sarei gentile se potessi dire: "Preferisco il inclinazione-verso-6NF (o qualsiasi altra cosa) stile me stesso. "

Supponendo che uno di questi approcci sia in effetti un anti-pattern (come ho solo il sospetto potrebbe essere il caso per l'approccio 1 modellando una relazione tra due entità come un attributo di una di quelle entità) questo anti-pattern ha un nome?

Answer 1

Bene, il primo non è altro che una relazione uno-a-molti (un dipendente per molti prodotti). Questa viene a volte indicata come una relazione O: M (da zero a molti) perché è facoltativa (non ogni prodotto ha un product manager). Inoltre, non tutti i dipendenti sono gestori di prodotti, quindi è facoltativo anche dall'altra parte.

La seconda è una tabella unirsi, di solito utilizzato per una relazione molti-a-molti. Ma dal momento che una parte è solo uno-a-uno (ogni prodotto è solo nella tabella una volta) è davvero solo una complicata relazione uno-a-molti.

Personalmente preferisco il primo, ma nessuno dei due è sbagliato (o cattivo).

Il secondo sarebbe utilizzato per due motivi che vengono in mente.

1. Si immagina la possibilità che un prodotto abbia più di un manager; o
2. si desidera tenere traccia della storia di chi è il responsabile di prodotto è per un prodotto. Lo fai con, diciamo una colonna current_flag impostata su 'Y' (o simile) dove solo uno alla volta può essere attuale. Questo è in realtà un modello piuttosto comune nelle applicazioni basate su database.

Answer 2

Sembra a me come il diverso comportamento di due modelli. Nel primo esempio, puoi avere un product manager per prodotto e un dipendente può essere product manager per più di un prodotto (uno a molti). Il secondo sembra consentire più di un product manager per prodotto (molti a molti). Ciò suggerirebbe che le due soluzioni sono ugualmente valide in diverse situazioni e che quella che usi dipenderà dalla regola aziendale.

Answer 3

c'è un difetto nel primo approccio. Immagina per un secondo che i requisiti aziendali siano cambiati e ora devi essere in grado di impostare 2 Product Manager su un prodotto. Cosa farai?Aggiungi un'altra colonna alla tabella Prodotto? Che schifo. Questo ovviamente viola 1NF allora.

Un'altra opzione offerta dal secondo approccio è la possibilità di memorizzare alcuni attributi per un determinato Product Manager < -> Relazione prodotto. Ad esempio, se hai due Product Manager per un prodotto, puoi impostarne uno come primario ... Oppure, ad esempio, un dipendente può avere un numero di telefono, ma come product manager può avere un altro numero di telefono ... Questo va anche al tavolo speciale allora.

Answer 4

Approccio 1)

1. Rallenta l'uso della tabella Product con il campo aggiuntivo Product Manager (forse non per tutti i database, ma per un po ').
2. Il collegamento dalla tabella Product alla tabella Employee è semplice.

Approach 2)

1. query esistenti utilizzando la tabella del prodotto non sono interessati.
2. Aumenta le dimensioni del database. Ora hai duplicato la colonna ID prodotto in un'altra tabella e aggiunto vincoli e indici univoci a quella tabella.
3. Il collegamento dalla tabella Product al tavolo Employee è più ingombrante e costoso in quanto è necessario innanzitutto importare sul tavolo intermedio.

Con quale frequenza è necessario il collegamento tra i due tavoli?

Quante altre query utilizzano la tabella Prodotto?

Quanti record nella tabella Prodotto?

Answer 5

nel caso specifico che si fornisce, penso che la motivazione principale per due tabelle sia evitare i valori nulli per i dati mancanti ed è così che vorrei caratterizzare i due approcci.

c'è una discussione sui pro e contro on wikipedia.

Sono sicuro che, data l'avversione per la data c, definisce la teoria relazionale in modo che solo la soluzione a più tabelle sia "valida". ad esempio, è possibile chiamare l'approccio alla tabella singola "mal digitato" (poiché il tipo di valore null è unclear - vedere la citazione su p4).