Дизайн базы данных - сохранение эквивалентности

Question

Я разрабатываю реляционную базу данных для системы, которая хранит информацию о некоторых типах продуктов, розничных торговцев и поставщиков для розничных продавцов.

Некоторые поставщики продают те же продукты, - тем не менее, они не имеют стандарт для идентификации продуктов, что означает Поставщику может иметь продукт с идентификатором 618261, что эквивалентно поставщиком продукта Б 007162.

Проблема в том, что я не хочу хранить один и тот же продукт несколько раз для разных поставщиков. В настоящее время у меня есть следующие таблицы:

эквивалентность

• supplier1_id
• supplier2_id
• supplier1_product_id
• supplier2_product_id

продукт

• идентификатор (генерируется)
• supplier_id
• supplier_product_id

Это кажется плохой идеей. Всякий раз, когда что-то вставляется в «продукт»,

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

Есть ли более разумный способ сделать это?

Answer 1

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

На простом английском языке поставщик может поставлять много продуктов, и продукт может быть доступен от многих поставщиков. Это отношение «многие ко многим» поддерживается через таблицу пересечений или пересечений. Если вы думаете об этом, номер SKU не является атрибутом объекта Product или субъекта Поставщика. Вместо этого это атрибут отношения. Да, отношения могут иметь атрибуты, как и любой объект.

create table ProductSupplier(
    ProductID int not null references Products(ID), 
    SupplierID int not null references Suppliers(ID), 
    UnitPrice currency not null, 
    SKU   varchar 
); 

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

Опять же на простом английском языке, кортеж из этой таблицы говорит, "этот продукт это поставщика имеет этого SKU номер."