Conception de base de données - Information de contact similaire pour plusieurs entités

Question

Je me rends compte que la réponse à ces types de questions est souvent "cela dépend" mais je me demande encore quel pourrait être le consensus général.

Je traite avec plusieurs entités telles que

1. Société
2. Charity
3. Commissaire aux comptes
4. Stocktaker

etc etc ...

qui ont tous contacts informations telles que e-mail, tel ephone et adresse.

Les deux méthodes de conception, je songeais à stocker les informations de contact ont été

Méthode 1) créer des tables de rôle entre les tables de contact et de l'entreprise, la charité, commissaire aux comptes et 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 < - d bo.telephone
• dbo.Auditor-> dbo.Auditoraddress < - dbo.email

Avantages, il n'a besoin que d'être une adresse, téléphone et table de base de données e-mail dans tous les numéros de téléphone et adresses, et des e-mails pour chaque type d'entité sont stockés dans un endroit Les inconvénients sont il crée beaucoup de tables associatives

Méthode 2) Création d'une table de contact séparée par entreprise, la charité, commissaire aux comptes et 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

Les avantages de ce sont plus faciles à i mplement and maintain Inconvénients sont les détails de contact sont stockés à plusieurs endroits dans la base de données.

Si quelqu'un a d'autres idées, il serait très apprécié.

Un grand merci

Answer 1

Vous avez raison lorsque vous dites "ça dépend". Cela dépend de ce que vos données seront utilisées pour OLTP, vous étudieriez une conception normalisée et un système de génération de rapports vous voudriez que les données soient normalisées avec les informations de contact en ligne avec les autres composants de données.

Dans la base de données normalisée, le niveau de normalisation peut également être débattu. Certains diront d'avoir des informations de contact granulaires comme dans votre premier scénario. J'aime aller "au milieu de la route" Je voudrais avoir toutes les informations de contact dans un tableau, qui comprenait l'adresse, le téléphone et l'email.

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

Ensuite, créez une relation avec une table séparée

CompanyContact 
ID, CompanyID, ContactID 

Cela aussi pourrait être intégré dans la table de la société, en ajoutant simplement un ContactID à la table entreprise et éviter la relation séparée et rejoindre.

Vous pouvez également implémenter une table avec ContactTypes.

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

Ensuite, vous pouvez spécifier que dans le tableau CompanyContact et de supprimer la nécessité d'une relation. Bien que cela corresponde à votre scénario de 1 contact par type, il ne laisse pas de place pour la croissance.

Answer 2

J'aime votre méthode 2 mieux, mais il semble encore trop de travail. Pourquoi ne pas simplement avoir un numéro de téléphone, une adresse, etc ... des tables qui stockent TOUTES les adresses, numéros de téléphone, whatevers, puis référencer cela de la compagnie, du vérificateur, etc ...? C'est probablement comme ça que je l'aurais fait.

Answer 3

Vous pouvez utiliser une seule table pour tous et utiliser les types de données comme ci-dessous.