Лучший способ обработки первичных записей связи в нормализованном дизайне - PullRequest
1 голос
/ 10 апреля 2011

Я выполнил поиск до публикации этого вопроса и не нашел ничего связанного напрямую, поэтому, если это дубликат, я прошу прощения. Я проектирую бизнес-систему, и, как и любая бизнес-система, у меня есть таблица «Клиенты» со столбцом «Идентификатор клиента PK».

Я работаю над таблицами телефонных номеров / адресов электронной почты, которые я хотел бы нормализовать таким образом, чтобы любой заданный CustomerID мог иметь несколько телефонных номеров и / или адресов электронной почты, когда меня поразила мысль. Большинство предприятий связывают один номер телефона для учетной записи любого человека и называют этот основной номер телефона. Этот номер телефона, скорее всего, будет отображаться в любых выписках, отчетах и ​​т. Д. То же, что и адрес электронной почты.

Я начал думать о том, как будет работать запрос SELECT, если я хочу получить список клиентов с указанием их основного телефона и адреса электронной почты. Очевидно, что я мог бы использовать Inner Join для получения информации, но я бы хотел, чтобы каждый CustomerID появлялся только один раз, если у CustomerID было два телефонных номера, тогда они появлялись бы дважды в списке.

Итак, моей первоначальной мыслью было создание таблицы под названием CustomerCommunications, хранение телефонных номеров и адресов электронной почты и добавление туда столбца FlagPrimary, но это не совсем имеет смысла, потому что как бы вы узнали, была ли одна запись номером телефона или адрес электронной почты. (Очевидно, что контент выдаст его, но с точки зрения запроса это будет сложно). Тогда я подумал о добавлении таблицы CommunicationTypes с отдельными строками для основного телефона и основной электронной почты. Затем в таблицу CustomerCommunications я добавлю внешний ключ CommunicationTypeID, который позволит мне легко определить, какой телефон был основным, а какой - основным. Но потом я начал думать о том, каким CommunicationTypeID будут другие записи телефона и адреса электронной почты. Просто телефон и электронная почта? Дополнительный телефон и электронная почта?

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

1 Ответ

1 голос
/ 10 апреля 2011

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

Если ваше бизнес-правило состоит в том, что первичными могут быть только один номер телефона и один адрес.и у них может быть столько других, сколько вам нужно, тогда способ реализовать это с помощью схемы базы данных состоит в том, чтобы поместить внешние ключи в таблицу клиентов, указывающие на контакты, которые являются первичными.Это означает, что ваша таблица PHONE_NUMBER имеет FK для CUSTOMER, а также CUSTOMER имеет FK для PHONE_NUMBER (например, primary_phone_number_id).То же самое будет верно для электронных писем.Если вы смешаете свои электронные письма и телефонные номера в одной таблице, вам все равно понадобится триггер или другая процедурная логика, чтобы убедиться, что вы указываете один телефонный номер и одно электронное письмо для каждого клиента.Это еще одно преимущество разделения ваших разных типов контактов на их собственные таблицы.FK могут выполнять всю тяжелую работу, и у вас нет потенциально ошибочного процедурного кода.

...