Se ho due tabelle nel mio database, diciamo ad esempio "acquirenti" e "venditori", ma raccolgo un insieme comune di dati sia per numero di telefono di esempio, indirizzo e-mail, indirizzo ecc. È una pratica migliore avere una tabella comune per 'contact_details' con un riferimento alla tabella e alla riga a cui sono destinati i dettagli del contatto, o dato che sono entità separate, stanno meglio in tavoli separati?
dovrei memorizzare dati comuni tra due tabelle in una terza tabella separata nel mio database?
3
5 risposte
6
Se "acquirenti" e "venditori" condividono molti dati, forse sono solo "contatti", con le informazioni di contatto associate. Se ogni contatto è un acquirente o un venditore dipenderebbe dal modo in cui sono stati utilizzati.
Ad esempio, potresti avere entrambe le tabelle "vendite" e "acquisti". Ciascuno avrebbe una colonna 'contact_id', quella collegata alla chiave primaria nella tabella 'contatti'.
risposta data
18.02.2014 - 12:55
fonte
4
Suggerirei tre tabelle: contatti, acquirenti e venditori. Tutti i dati comuni sono tenuti in contatto e qualsiasi cosa specifica per essere un acquirente e / o un venditore sarebbe contenuta in quelle tabelle con una sorta di relazione 1: 1. Il fatto che esiste una relazione li classifica come acquirente e / o venditore.
Se non hai mai avuto bisogno di un elenco combinato dei due (ovviamente puoi unire due tabelle) o la possibilità di mantenere un singolo contatto che potrebbe appartenere a entrambi, non dovresti preoccuparti di questo.
risposta data
18.02.2014 - 13:22
fonte
3
Impossibile dire in generale.
Più campi contengono i tuoi dati di contatto, maggiore è il rischio che il mantenimento di questi dati richieda un codice duplicato. Ma più spesso recuperi i record di acquirenti e venditori, maggiore è il rischio che il JOIN richiesto da una tabella separata diventi un collo di bottiglia per le prestazioni.
Come vedi, la decisione ha sia tempo di esecuzione che conseguenze sul tempo di sviluppo, e la cosa da fare è stimare quale sarà il modello di utilizzo tipico. Allora saprai se la normalizzazione del tuo schema è un vantaggio generale o meno. (In caso di dubbi, è difficile prevedere le misure e gli sconti sulle prestazioni.)
risposta data
18.02.2014 - 12:33
fonte
1
I miei due centesimi:
- Il contatto può essere un acquirente, un venditore, entrambi o solo un contatto.
- Il contatto può avere più numeri di telefono e indirizzi.
- La tabella dei contatti ha attributi di contatto di base.
- Acquirente e venditore hanno attributi che si applicano solo a quel ruolo.
- Un contatto che non è né un acquirente né un venditore non ha righe correlate in quelle tabelle
risposta data
18.02.2014 - 19:41
fonte
0
È comune nel tuo sistema che "acquirente" e "venditore" condividano un indirizzo?
Scommetto che non lo è e per questo vorrei discutere di non avere un tavolo separato.
risposta data
24.10.2016 - 00:37
fonte
Leggi altre domande sui tag database-design