Лучший способ к модели Customer <-> Адрес

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

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

Customer (id, ...)
Address (id, customer_id, address_type, valid_from, valid_to)

, С другой стороны, если Вы не должны обслуживать это (и Вы уверены, что не будете в будущем), тогда, вероятно (1) более просто справиться, потому что намного легче поддержать целостность данных, поскольку нет никаких проблем с обеспечением только одного адреса того же типа, существует, и соединения становятся более простыми, как они находятся только на одном поле.

Так или (1) или (2) прекрасны в зависимости от того, нужны ли Вам перемещения дома, но я избегал бы (3), потому что Вы тогда повторяете определение того, что адрес находится в таблице, и необходимо будет добавить несколько столбцов, если Вы изменяете то, на что похож адрес. Это возможно немного более производительно, но быть честным, когда Вы имеете дело с правильно индексируемым, участвует в реляционной базе данных нет много, чтобы быть полученным, и это, вероятно, будет медленнее в некоторых сценариях, где Вы не делаете , нуждаются в адресе, поскольку рекордный размер для клиента будет больше.

При ответе на те виды вопросов мне нравится использовать классификации DDD. Если это - Объект, это должно иметь отдельный идентификатор, если это - объект значения, что это не должно.

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

Я предпочел бы № 1. Хорошая нормализация и передает намерение ясно. Эта модель также позволяет тот же объект адреса (строка) использоваться для обоих адресов, что-то, что я нашел, чтобы быть довольно ценным. Слишком легко потеряться в дублировании этой информации слишком много.

Опция 3 слишком строга, и опция 1 не может быть расширена для обеспечения других типов адресов, не изменяя схему. Опция 2 является ясно самой гибкой и поэтому лучший выбор.

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

, Когда дополнительный почтовый адрес необходим, я поместил его в отдельный объект / таблица для не создания помех потребительскому объекту к очень.

Ранее в моей карьере я нормализовал как безумное наличие порядка, ссылающегося на клиента, который ссылается на адрес поставки. Это сделало вещи "чистыми", но медленными и неэлегантными для использования. В наше время я использую объект порядка, который просто содержит всю адресную информацию. Я на самом деле считаю это более естественным, так как клиент мог бы изменить его (значение по умолчанию?) адрес, но адрес отправки отправляет, в 2007 должен всегда оставаться таким же - даже если клиент перемещается в 2008.

Мы в настоящее время реализуем VerySimpleAddressProtocol в проекте стандартизировать используемые поля.

Я пошел бы для первой опции. В этих ситуациях я являюсь очень утомленным от YAGNI (Вы не испытываете необходимость в нем). Я не могу считать количество раз, я посмотрел на схемы, это имело one-many таблицы, "просто упаковывают", которые многие годы. Если Вам только нужно два, просто используйте первую опцию; если изменения требования в будущем, измените его тогда.

Как во многих случаях: Это зависит.

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

В случаях, где только необходимо знать один адрес клиента, почему Вы смоделировали бы это к - многие? К - отношения удовлетворили бы Ваши потребности здесь.

Важный: Денормализуйте, только если Вы встречаетесь с проблемами производительности.

Я пошел бы с опцией 1. Если Вы хотите, Вы могли бы даже изменить его немного для хранения истории адреса:

Customer   (id, phys_address_id, mail_address_id)
Address    (id, customer_id, start_dt, end_dt, street, city, etc.)

, Если адрес изменяется, только дата окончания текущий адрес и добавляет новую запись в Address таблица. phys_address_id и mail_address_id всегда точка к текущему адресу.

Тот способ, которым можно сохранить историю адресов, у Вас могло быть несколько почтовых адресов, сохраненных в базе данных (со значением по умолчанию в mail_address_id), и если физический адрес и почтовый адрес будут идентичны, то Вы просто укажете phys_address_id и mail_address_id в той же записи.

Мы движемся вперед с такой моделью, как эта:

Person (id, given_name, family_name, title, suffix, birth_date)
Address (id, culture_id, line1, line2, city, state, zipCode, province, postalCode)
AddressType (id, descriptiveName)
PersonAddress (person_id, address_id, addressType_id, activeDates)

Большинство может счесть это излишним. Однако, бесспорной общей темой среди разрабатываемых нами приложений является то, что у них будут некоторые из этих фундаментальных сущностей - Люди, Организации, Адреса, Телефонные номера и т.д.. - и все они хотят комбинировать их по-разному. Итак, мы строим вначале некое обобщение, для которого мы на 100% уверены, что у нас есть примеры использования.

Таблица адресов будет следовать схеме наследования по таблице иерархии для дифференциации адресов в зависимости от культуры; таким образом, адрес в США будет иметь поле штата и zip, а адреса в Канаде будут иметь провинциальный и почтовый индекс.

Мы используем отдельную соединительную таблицу, чтобы "дать" человеку адрес. Благодаря этому наши другие организации - Person & Address - остаются свободными от связей с другими организациями, когда, по нашему опыту, это, как правило, усложняет дело. Это также значительно упрощает подключение адресных объектов ко многим другим типам объектов (Люди, Организации и т.д.) и с различной контекстной информацией, связанной с этой ссылкой (например, activeDates в моем примере)