Как хранить информацию в БД о поставщиках когда они могут являться разынми сущностями?

Задача: необходимо спроектировать БД для магазина. В БД необходимо организовать учет поставщиков, чтобы на них можно было ссылаться из таблицы "Поставка" . Проблема в том, что поставщиком может быть как физическое лицо (самозянятый) индивидуальный предприниматель или юридическое лицо (т.е. создать для них одну таблицу с первичным ключом кажется не совсем корректным). Как все эти разные сущности хранить в БД?

У меня пока что возникла идея создать промежуточную таблицу с внешними ключами для трех таблиц ("ФЗ", "ИП", "ЮЛ"). Т.е. для каждой сущности создать отдельную таблицу.
633d5fa44f900198243021.jpeg
Прошу обратить внимание на саму структуру и организацию связей таблиц, так как таблицы полями наполнял на скорую руку.
  • Вопрос задан
  • 214 просмотров
Решения вопроса 2
Vindicar
@Vindicar
Это, по сути, наследование. Абстрактный класс-предок (поставщик) и конкретные классы-потомки (физлицо, ИП, организация). Наследование обычно выражается в структуре БД так: создаётся таблица "Поставщик", содержащая общие для всех классов поля и имеющая свой ключ.
Затем под каждый класс-потомок создаётся отдельная таблица, содержащая сведения, уникальные для этого класса. В этой таблице первичный ключ одновременно является внешним ключом, ссылающимся на таблицу "Поставщик". Иными словами, в таблице-потомке могут быть только записи с ключами, которые есть в таблице "Поставщик", а для каждой записи в "Поставщик" будет не более одной записи в таблице-потомке.

В таблице "Поставщик" также может быть поле, указывающее на конкретный тип поставщика (физлицо, ИП, организация), т.е. в какой таблице искать остальные данные. Наличие или отсутствие этого поля - вопрос вкуса. В принципе, если нам нужны сведения о конкретном типе поставщика, мы можем попытаться сделать INNER JOIN с нужной конкретной таблицей. Это отсеет все записи других типов.
Такой подход (без поля типа) позволяет избежать противоречий, когда запись находится в одной таблице-потомке, а поле указывает на другую. Но с другой стороны, если мы не знаем, какой конкретный тип у данного поставщика, нам придётся либо перебирать таблицы-потомки в рамках нескольких запросов к БД, либо делать LEFT JOIN со всеми таблицами-потомками, и смотреть, какие поля не будут NULL.

Слабая сторона такой схемы в том, что связь по внешнему ключу не запрещает существование записей в нескольких таблицах-потомках, ссылающихся на одну и ту же запись в "Поставщике". Это придётся контролировать отдельно, триггерами или хранимыми процедурами.
Ответ написан
firedragon
@firedragon
Senior .NET developer
Отнаследуйте любого продавана от базового класса, а дальше добавьте поле кто он такой
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
То, что Vindicar в общем-то правильно назвал "наследованием" в контексте моделирования РБД иногда называют subtype relationship или inheritance hierarchy, можете поискать примеры по этим терминам.
Ответ написан
Комментировать
Sanes
@Sanes
id, title, profile_id для поставщика. К нему прикрепляете таблицу профиля. У каждой сущности свой набор полей в профиле.
К поставщику можете добавить другие поля, которые будут у всех типов пересекаться. Или что-то служебное, типа type или type_id.
Тут можно провести аналогию с группами пользователей и посмотреть разные варианты реализации..
Ответ написан
Комментировать
@v__V__v
Разработчик
Почитайте про полиморфные связи.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы