Datenbank-Design - ähnliche Kontaktinformation für mehrere Entitäten

Question

Ich weiß, dass die Antwort auf diese Art von Fragen sind oft „es kommt“, aber immer noch frage ich, was der allgemeine Konsens sein könnte.

Ich beschäftige mich mit mehreren Einheiten wie

1. Unternehmen
2. Charity
3. Auditor
4. Stocktaker

etc etc ...

, die alle Kontaktinformationen wie E-Mail, Telefon und Adresse.

Die beiden Design-Methoden, die ich dachte, die Kontaktinformationen zu speichern waren

Methode 1) erstellen Rolle Tabellen zwischen den Kontakttabellen und Unternehmen, Wohltätigkeit, Wirtschaftsprüfer und 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

Vorteile, es muss nur eine Adresse sein, Telefon und E-Mail-Tabelle in der Datenbank und alle Telefonnummern, Adressen und E-Mails für jeden Entitätstyp an einem Ort gespeichert werden Nachteile sind es viele assoziative Tabellen erstellt

Methode 2) Erstellen Sie eine separate Kontakttabelle pro Unternehmen, Wohltätigkeit, Wirtschaftsprüfer und 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

Vorteile sind einfacher zu implementieren und zu pflegen Nachteile sind Kontaktdaten an mehreren Standorten in der Datenbank gespeichert sind.

Wenn jemand noch andere Ideen hat, würde es sehr geschätzt werden.

Vielen Dank

Answer 1

Sie sind richtig, wenn Sie sagen, „es kommt“. Es hängt davon ab, was Ihre Daten für OLTP verwendet werden Sie bei einem normalisierten Design aussehen würde, und ein Meldesystem würden Sie die Daten wollen de-normalisiert mit den Kontaktinformationen inline mit den anderen Datenkomponenten.

In der normalisierten Datenbank, die Höhe der Normalisierung kann auch diskutiert werden. Einige werden sagen, um Kontaktinformationen granulare haben, wie Sie in Ihrem ersten Szenario haben. Ich mag „mitten auf der Straße“ gehen, würde ich alle Kontaktinformationen in einer Tabelle hat, die Adresse enthielt, Telefon und E-Mail.

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

Dann erstellen Sie eine Beziehung mit einer separaten Tabelle

CompanyContact
ID, CompanyID, ContactID

Auch diese in die Firma Tisch integriert werden könnten, nur um eine ContactID der Gesellschaft Tabelle hinzufügen und die getrennte Beziehung zu vermeiden und verbinden.

Sie können auch eine Tabelle mit ContactTypes implementieren.

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

Dann könnte man, dass in der CompanyContact Tabelle angeben und die Notwendigkeit für eine Beziehung entfernen. Obwohl es Ihr Szenario von 1 Kontakt pro Typ passt, ist es nicht Raum für Wachstum verlassen.

Answer 2

Ich mag Ihre Methode 2 besser, aber es scheint immer noch zu viel Arbeit. Warum haben nicht nur eine Telefonnummer, Adresse, etc ... Tabellen, die alle Adressen speichern, Telefonnummern, whatevers, dann entnehmen, dass bei der Gesellschaft, Wirtschaftsprüfer, etc ...? Es ist wahrscheinlich, wie ich es getan haben.

Answer 3

Sie können eine einzelne Tabelle für alle und Verwendung Datentypen wie unten verwenden.