Как я могу хранить контактные методы (или аналогичные типизированные данные с разными полями) в обычном порядке? - PullRequest
Новая
       16

Как я могу хранить контактные методы (или аналогичные типизированные данные с разными полями) в обычном порядке?

3 голосов
/ 11 марта 2009

Я сталкивался с этой проблемой в каждом приложении, которое когда-либо писал. Я хотел бы получить окончательный консенсусный ответ!

Является ли это наиболее нормализованным / эффективным / правильным способом хранения контактных методов или любых других данных по этому шаблону в базе данных? 

Contact { PK ContactId, ... }

ContactContactMethod {PK FK ContactId, PK FK ContactMethodId, Key, Comments }

AddressContactMethod {PK FK ContactMethodId, Line1, Line2, City, State, Zip }
EmailContactMethod {PK FK ContactMethodId, EmailAddress }
InstantMessengerContactMethod {PK FK ContactMethodId, IMClient, IMAddress }
PhoneContactMethod {PK FK ContactMethodId, ... }
WebsiteContactMethod {PK FK ContactMethodId, ... }
OtherContactMethod {PK FK ContactMethodId, ... }

Следует ли мне рассматривать поле Xml для ContactMethodData в таблице ContactContactMethod?

Что-то не так в адресах AddressContactMethod, EmailContactMethod и т. Д., Которые имеют одинаковую уникальность первичных ключей.

Также подумал о ключе, паре значений для контактных данных, но это было бы еще более сложной задачей, чем поле Xml.

(Рекомендации по проектированию: каждый контакт может иметь более одного или ни одного из каждого типа метода контакта, каждый с неуникальным «ключом», таким как «дом, работа, красная машина и т. Д.» И комментариями, но без других общих данных элементы между типами)

Ответы [ 5 ]

2 голосов
/ 11 марта 2009

Существует имя для этого шаблона. Это называется "обобщение специализации".

В этом случае методы контакта являются специализированными способами контакта с контактом.

Поиск в сети по «реляционному дизайну специализации обобщения» приведет вас к некоторым статьям, имеющим более общий характер. Для объекта с ориентированным представлением того же шаблона выполните поиск по «Проектирование объекта специализации обобщения».

2 голосов
/ 11 марта 2009

Как и вы, я видел больше, чем моя доля дизайнов базы данных контактной информации. Я думаю, что вы вполне разумны, и расположение столбца Key отдельно от таблиц * Method является приятным штрихом, позволяющим группировать «домашнюю» электронную почту и почтовые адреса по группам по моде.

Однако я думаю, что большинство контактных баз данных чрезмерно спроектированы. Хотя я не согласен с подходом Криса Лайвли, я думаю, вы могли бы упростить его, просто указав контактную информацию (адрес электронной почты, телефон, веб-адрес и т. Д.) И сохранив для каждого простую текстовую строку. Попытка проверить отдельные типы или разбить их на подполя обычно не стоит усилий. Во-первых, все правила проверки телефона и адреса немедленно исчезают, если вы разрешаете контакты за пределами США. Сохраните полный адрес в строке Unicode, и надеюсь на лучшее - мой совет.

Это оставляет дизайн примерно таким: 

Contact { PK ContactId, ... }
ContactType { PK ContactTypeId, ContactType }
ContactMethod {PK FK ContactId, PK FK ContactTypeId, PK Key, Value, Comments }

ContactMethod.Value - это текстовое значение.

Это похоже на то, как Google отслеживает контакты, по крайней мере. И если ничего другого, они, вероятно, продумали проблему отслеживания миллиардов контактов из каждой нации на Земле.

1 голос
/ 11 марта 2009

В былые времена я бы использовал схему таблиц - что-то вроде: 

Person [ID, Name]
ContactPoint [ID, PersonID, ContactMethod]
EmailContactPoint [ID, EmailAddress]
AddressContactPoint [ID, Line1, Line2, blah]

С отношением 1-1 между различными контактными точками и таблицей ContactPoint - своего рода наследование. ORM, такие как Hibernate / NHibernate и Entity Framework, могут создавать экземпляры правильного типа на основе этих отношений 1-1.

В настоящее время я бы, вероятно, просто пошел с большим двоичным объектом XML и парой функций в SQL, чтобы упростить работу со стандартной / основной точкой контакта для определенного типа (например, «GetPrimaryPhoneNumber (personID)».

1 голос
/ 11 марта 2009

Окончательный консенсусный ответ заключается в том, что собственный ответ каждого является лучшим, а никто не стоит цента. Это проблема; не существует единственного способа удовлетворить потребности каждого. Таким образом, вероятно, никогда не будет окончательного согласованного ответа - может быть, даже не согласованного ответа, но почти наверняка не окончательного.

0 голосов
/ 11 марта 2009

Большинство людей действительно за архитектором. Посмотрите на это таким образом, сколько телефонных номеров для конкретного контакта вы действительно заботитесь? Обычно 1; иногда 2.

То же самое для адресов, обычно все, что вам действительно нужно, это файл.

Итак, помня об этом, посмотрите на ваше приложение. Если у вас действительно есть только 2 телефонных номера, сохраните их в таблице CONTACT как HomePhone, WorkPhone или как угодно. Если в какой-то момент в будущем вы решите, что вам нужно больше телефонных номеров, тогда разберитесь в отдельные таблицы. То же самое для адресов. То же самое для электронной почты.

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

Подводя итог: держите базу данных настолько простой, насколько это возможно. Команда UI и ваш сервер базы данных будут вам благодарны.

...