Многие ко многим, промежуточная таблица или ячейка с массивом ключей?

Question

[iplaton]

Есть две таблицы. Продукты и поставщики. Продукт может поставляться разными поставщиками, но иметь только одного производителя, который одновременно является поставщиком и находится в таблице поставщиков. Склоняюсь к мысли отказаться от связующей промежуточной таблицы. Думаю в таблице продуктов создать внешний ключ указывающий на поставщика - производителя, а первичные ключи остальных поставщиков, не являющихся производителями, хранить просто в сериализованном массиве в ячейке таблицы продуктов. Или все таки лучше пойти классическим путем и делать промежуточную таблицу? Просто не хочется в рамках ORM городить еще один класс(это уже на клиенте php), для промежуточной таблицы.

Answer 1

[Иван Филатов]

1. Если выбрать путь ячейки с массивом ключей - то будет блокировка обновления записи, через Concurrency Token или через какой другой механизм. Но если у вас реализована очередь (EventBus, Rabbit) то конкуренции не будет.
Еще проблема - JOIN таблиц, построение сложных запросов. Т.к. индексировать вашу ячейку сериализованную проблематично - то при запросах будет SCAN - производительность упадет на больших объемах.

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

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