Проектирование базы данных - похожая контактная информация для нескольких лиц - PullRequest
Новая
       15

Проектирование базы данных - похожая контактная информация для нескольких лиц

3 голосов
/ 03 сентября 2010

Я понимаю, что ответы на эти типы вопросов часто бывают «все зависит», но все же мне интересно, каким может быть общее согласие.

Я имею дело с несколькими субъектами, такими как

  1. Компания
  2. Благотворительность
  3. Аудитор
  4. Торговец чеками

и т. Д. И т. Д. *

Которые имеют контактную информацию, такую ​​как электронная почта, телефон и адрес.

Два метода проектирования, о которых я думал, чтобы хранить контактную информацию:

Метод 1) создание таблиц ролей между таблицами контактов и компанией, благотворительной организацией, аудитором и биржевым агентом.

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

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

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

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

Преимущества, требуется только один адрес, телефон итаблица электронной почты в базе данных, и все телефонные номера, адреса и электронные письма для каждого типа организации хранятся в одном месте. Недостатками является создание множества ассоциативных таблиц

Метод 2) Создание отдельной таблицы контактов для каждой компании, благотворительной организации, аудитораи биржевой маклер

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

  • dbo.Company -> dbo.CompanyContactадрес

  • dbo.Auditor -> dbo.AuditorContactAddress

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

Преимущества этого легче реализовать и поддерживать Недостатки - контактдетали хранятся в нескольких местах по всей базе данных.

Если у кого-то есть какие-либо другие идеи, это будет высоко оценено.

Большое спасибо

Ответы [ 3 ]

1 голос
/ 03 сентября 2010

Вы правы, когда говорите "это зависит".В зависимости от того, какие ваши данные будут использоваться для OLTP, вы будете рассматривать нормализованный дизайн и систему отчетности, для которой вы хотите, чтобы данные были нормализованы с помощью контактной информации, встроенной в другие компоненты данных.

Внормализованная база данных, уровень нормализации также можно обсудить.Некоторые скажут, что контактная информация должна быть гранулированной, как в первом сценарии.Мне нравится идти «в середине пути». Я бы имел все контактные данные в одной таблице, включая адрес, телефон и электронную почту. 

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

Затем создайте связь с отдельной таблицей 

CompanyContact
ID, CompanyID, ContactID

Это также можно интегрировать в таблицу компании, просто добавив ContactID в таблицу Company и избегая отдельных отношений и объединения.

Вы также можете реализовать таблицу с ContactTypes.

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

Затем вы можете указать это в таблице CompanyContact и устранить необходимость в связи.Хотя он соответствует вашему сценарию с 1 контактом на тип, он не оставляет места для роста.

0 голосов
/ 03 сентября 2010

Вы можете использовать одну таблицу для всех и использовать типы данных, как показано ниже.alt text

0 голосов
/ 03 сентября 2010

Мне больше нравится ваш метод 2, но он все еще кажется слишком сложным.Почему бы просто не иметь таблицы PhoneNumber, Address и т. Д., В которых хранятся ВСЕ адреса, номера телефонов и т. Д., А затем ссылаться на них из компании, аудитора и т. Д.Наверное, так бы и сделал.

...