Каков наилучший подход для разработки таблиц для клиента и адреса, для которых у клиента есть основной адрес?

Question

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

Я определил следующие решения, у вас есть какие-нибудь другие?

Решение 1:

Table Clients
+ name
+ surname
Table Addresses
+ line1
+ city
+ country
+ postcode
+ flag_primary

Решение 2:

Table Clients
+ name
+ surname
+ primary_address_id

Table Addresses
+ line1
+ city
+ country
+ postcode

Решение 3:

Table Clients
+ id
+ name
+ surname

Table Addresses
+ id
+ user_id
+ line1
+ city
+ country
+ postcode

Table User_Settings
+ user_id
+ address_id

Пожалуйста, объясните, почему вы считаете, что ваше предложение является правильным.

Answer 1

ЯСНО, сделай решение 2.

Логический: когда клиент меняет свой основной адрес, это не меняет адрес. Это отражено в схеме БД

Коррупция: нет никакого способа, которым вы, бд, становитесь странным, имея клиента с двумя основными адресами. Решение 1 может иметь два логических флага в true.

Простота: когда вы изменяете адрес клиента, вы можете сделать это с помощью одного обновления. Для решения 1 вы делаете 2 обновления ... возможно, в одном сложном SQL-запросе, но это два обновления!

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

Совместим со всеми системами контроля версий: клиент меняет свой основной адрес? => клиент обновлен => сохранить старую версию или обновленные строки для этого клиента. С решением 1 вы сломаете его или вам придется изменить поведение по умолчанию самостоятельно.

Редактировать : хорошо, если вы отредактируете свой вопрос после того, как мы ответили на него, наши ответы будут выглядеть глупо.

Рекомендую вам это, если вы планируете иметь более одного адреса для каждого клиента, но все же основной

client
    primary_address (fk to address(id))

address
    client (fk to client(id))

Answer 2

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

Я бы выбрал отношение «многие ко многим» между клиентом и адресом с флагом, указывающим, какой адрес является основным. Или даже тип ("почтовый", "визит", ...)

стол client

• id (PK)
• first_name
• last_name

стол address

• id (PK)
• line1
• city
• postcode
• ....

стол client_address

• address_id (от FK до address)
• client_id (от FK до client)
• is_primary (логическое, true / false)

В зависимости от фактического продукта базы данных «только один основной адрес на клиента» может быть применен с уникальным ограничением на таблицу client_address

Answer 3

Поскольку есть две сущности - Клиент и Адрес

Адрес будет существовать только тогда и только тогда, когда существует Клиент с этим адресом. Таким образом, существует зависимость Address сущности от Client сущности, так что вы можете иметь client_id в адресной сущности в качестве внешнего ключа.

У вас может быть что-то вроде этого:

Table Clients
+ client_id
+ name
+ surname

Table Addresses
+ line1
+ city
+ country
+ postcode
+ flag_primary
+ client_id [FOREIGN_KEY]