обнуляемые внешние ключи и общий родительский ключ

Question

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

Решение 1:

• Таблица клиентов

• Таблица поставщиков

• Таблица филиалов

• Таблица адресов с обнуляемым значениемвнешние ключи для CustomerID, VendorID, BranchID

Решение 2:

• Таблица сущностей

• Customerтаблица с EntityID

• Таблица поставщиков с EntityID

• Таблица филиалов с EntityID

• Таблица адресов сEntityID и флаг EntityType 'C', 'V' или 'B'

Решение 3 (предложено AJC):

• Таблица клиентов

• Таблица поставщиков

• Таблица филиалов

• Таблица адресов

• Таблица внешних ссылок CustomerAddress между Customer и Address

• Таблица внешних ссылок VendorAddress между поставщиком и адресом

• Таблица внешних ссылок BranchAddress между филиалом и адресом

Решение 4 (предложено 9000)

• Таблица клиентов

• Таблица поставщиков

• Таблица филиалов

• CustomerAddress с FK для клиента

• VendorAddress с FK для поставщика

• BranchAddress с FK дляВетвь

• vwAddress, который UNION ALL объединяет каждую из приведенных выше таблиц адресов и включает флаг типа ('B', 'C', 'V')

Примечания:

У каждого клиента, поставщика или филиала может быть несколько адресов, но должен быть хотя бы один.

Если «сущность» является одновременно клиентом и поставщиком,он может иметь отдельные адреса для каждой роли.

Хотелось бы узнать, является ли клиент также поставщиком.

Answer 1

(Это то, что сказал @AJC, только что объяснил.)

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

Решение 2 позволяет потенциально назначать адрес типа «B» Клиенту и т. Д. Возможно, это также не то, что вам нужно.

Насколько я понимаю ваше намерение, вы должны иметь возможность назначать несколько адресов сущности, но не наоборот.

Создание таблицы адресов для вида объекта: CustomerAddress с FK, ссылающимся на Customer, VendorAddress с FK на Vendor и т. Д. Кроме строгой ссылочной целостности и невозможности назначить адрес неправильного типа, это покупает Вы можете расширять каждый тип адреса дополнительными полями, которые имеют для него смысл.

Чтобы упростить запрос ко всем адресам, вы можете создать представление Address, которое будет включать общие поля и флаг типа ('B', 'C', 'V'), чтобы увидеть, что это за адрес.

Answer 2

C) Ничего из вышеперечисленного.

Правильный способ сделать это состоял бы в том, чтобы иметь Таблицу адресов и CustomerAddress, VendorAddress и BranchAddress соответственно, чтобы соединить каждый объект C V B с одним или несколькими адресами.

Для атрибутов «один к одному», очевидно, нет необходимости в дополнительных таблицах, вы просто добавляете Id в основную таблицу (AddressId) ...