Общая таблица "один ко многим" для нескольких сущностей

Я бы сказал, что недостающий фрагмент головоломки - это отношение «есть», которое часто упускается из виду при моделировании данных; это отличается от знакомого отношения «имеет». Отношение «есть» похоже на отношение наследования в объектно-ориентированном дизайне. Чтобы смоделировать это, вам понадобится базовая таблица, которая представляет общие атрибуты поставщиков и клиентов. Например, мы могли бы назвать базовую таблицу «Организации»:

Organizations       Vendors               Customers
--------------      ---------------------  ---------------------
OrganizationID(PK)  OrganizationID(FK/PK)  OrganizationID(FK/PK)
AddressID1(FK)
AddressID2(FK)

В этом примере «Поставщик» - это организация, а «Заказчик» - «организация, а у организации« есть »адрес. Таблицы "Организации", "Поставщики" и "Клиенты" имеют общий ключ и общую последовательность ключей, обеспечиваемую ссылочной целостностью.

Я думаю, что из трех вариантов, которые вы указали, я был бы наиболее склонен выбрать вариант 1. Обычно у клиента или поставщика не более нескольких разных адресов, но если они есть, возможно, решение, приведенное ниже, будет работать лучше. для тебя. Я бы не стал выбирать вариант 2, потому что, вероятно, нет смысла связывать адрес и с покупателем, и с продавцом одновременно. Я знаю, что вы, вероятно, зададите только один из этих идентификаторов за раз, но модель может сбивать с толку, и вам может потребоваться добавить специальную логику, чтобы убедиться, что для любой данной записи установлен только CustomerID или VendorID. Я бы определенно не стал использовать вариант 3, потому что вы не можете сделать FKID настоящим FK. Если вы хотите, чтобы столбец ссылался на несколько таблиц, вы не сможете использовать ограничение FK в базе данных для его принудительного применения. Кроме того, если вы планируете использовать ORM для взаимодействия с базой данных в коде, у них, как правило, возникают проблемы с обработкой «поддельных» внешних ключей, которые ссылаются на несколько таблиц в зависимости от отдельного столбца «дискриминатор».

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

Customer
--------
CustomerID (PK)

Vendor
------
VendorID (PK)

Address
-------
AddressID (PK)

CustomerAddress
---------------
CustomerID (FK/PK)
AddressID (FK/PK)

VendorAddress
-------------
VendorID (FK/PK)
AddressID (FK/PK)

Как насчет четырех таблиц, одна из которых служит шлюзом для адресов? Так что у вас будет

Customer
    customerId (PK)
    addressBookId (FK to AddressBook)

Vendor
    vendorId (PK)
    addressBokId (FK to AddressBook)

AddressBook
    addressBookId (PK)

Address
    addressId (PK)
    addressBookId (FK to AddressBook)

Можете ли вы изменить дизайн таблицы, чтобы в ней были следующие поля:

 Address_Type  (a flag to say that this is a customer, or a vendor)
 ID            (a common ID for both customer and vendor and depending on the flag you know what ID it is)
 Address       (Data of address itself)

или у вас может быть две таблицы:

• Address table, where no reference to types of address it is. i.e. to have both
  • entity ID (key)
  • Адрес
• address type table, where it would point at entry and have the flag outside the table to have:
  • entity ID (FK to entity ID in the above table)
  • тип организации (покупатель или поставщик)