Progettazione di database - Informazioni di contatto simile per entità multiple

Question

Mi rendo conto che la risposta a questi tipi di domande sono spesso "dipende" ma ancora chiedendo che cosa potrebbe essere il consenso generale.

ho a che fare con più entità come

1. Società
2. Carità
3. Sindaco
4. Stocktaker

ecc ecc ...

Che hanno tutte le informazioni di contatto quali e-mail, telefono e indirizzo.

I due metodi di progettazione stavo pensando di memorizzare le informazioni di contatto sono stati

Metodo 1) creare le tabelle di ruolo tra le tabelle di contatto e società, la carità, revisore dei conti e stocktaker.

• dbo.Company -> dbo.CompanyAddress <- dbo.Address
• dbo.Company -> dbo.Companytelephone <- dbo.telephone

• dbo.Company -> dbo.Companyaddress <- dbo.email

• dbo.Auditor-> dbo.AuditorAddress <- dbo.Address

• dbo.Auditor-> dbo.Auditortelephone <- dbo.telephone
• dbo.Auditor-> dbo.Auditoraddress <- dbo.email

I vantaggi, non ha solo bisogno di essere un indirizzo, telefono ed e-mail in tabella di database e tutti i numeri di telefono, indirizzi e-mail per ogni tipo di entità sono memorizzate in un unico luogo Gli svantaggi sono che crea un sacco di tavoli associativi

Metodo 2) Creare una tabella contatto separato per azienda, la carità, revisore dei conti e stocktaker

• dbo.Company -> dbo.CompanyContactAddress
• dbo.Company -> dbo.CompanyContacttelephone

• dbo.Company -> dbo.CompanyContactaddress

• dbo.Auditor -> dbo.AuditorContactAddress

• dbo.Auditor -> dbo.AuditorContacttelephone
• dbo.Auditor -> dbo.AuditorContactaddress

I vantaggi di questo sono più facili da implementare e mantenere Gli svantaggi sono contatti sono memorizzati in più sedi in tutto il database.

Se qualcuno ha altre idee sarebbe molto apprezzato.

Molte grazie

Answer 1

Hai ragione quando dici "dipende". Dipende da quello che saranno utilizzati per i dati OLTP si dovrebbe guardare a un disegno normalizzato, e un sistema di reporting che si vorrebbe i dati de-normalizzata con la linea informazioni di contatto con gli altri componenti di dati.

Nel database normalizzato, il livello di normalizzazione può anche essere discussa. Alcuni diranno di avere informazioni di contatto granulari come avete nel vostro primo scenario. Mi piace andare "mezzo alla strada" Vorrei avere tutte le informazioni di contatto in una tabella, che comprendeva indirizzo, telefono ed e-mail.

Contact
ID, Address, Address2, City, State, Zip, Phone, Email

Quindi creare una relazione con una tabella separata

CompanyContact
ID, CompanyID, ContactID

Anche questo potrebbe essere integrato nella tabella società, semplicemente aggiungendo un ContactID alla tabella Società ed evitare il rapporto separato e unirsi.

Si potrebbe anche implementare un tavolo con ContactTypes.

ContactType 
ID, ContactType
1, Company
2, Charity
3, Auditor
....

Poi si potrebbe specificare che nella tabella CompanyContact e rimuovere la necessità di un rapporto. Anche se si inserisce lo scenario di 1 per ogni tipo che non lascia spazio per la crescita.

Answer 2

Mi piace il metodo 2 meglio, ma sembra ancora troppo lavoro. Perché non basta avere un PhoneNumber, indirizzo, ecc ... le tabelle che memorizzare tutti gli indirizzi, numeri di telefono, whatevers, poi di riferimento che da parte della Società, Sindaco, ecc ...? E 'probabilmente come avrei fatto.

Answer 3

Si potrebbe usare un unico tavolo per tutti ed i tipi di utilizzo di dati come qui di seguito.