Как лучше построить архитектуру БД, если планируется поиск по нескольким видам/типам товаров?

Question

[svilkov87]

Добрый день!

Планируется, что в проекте ассортимент товаров будет из как минимум 15 направлений...
- кирпич, смеси, кровля, утеплители итд... - и так до 15, как минимум.

В результатах поиска должно отображаться:
id, name.

Вопрос - сделать на каждую группу товаров свою таблицу и полями id, name и выборку делать с UNION ALL?
Или делать одну таблицу для всех групп товаров и выбирать id и name только в ней? Но в этом случае полей в этой таблице будет очень много. Ведь у каждой номенклатуры есть описание, подробные характеристики итд... А некоторые поля будут пустые, т.к. у кирпича, например, есть такие характеристики, которых нет у кровли...

Надеюсь, суть вопроса понятна, буду благодарен за ответ.
Спасибо.

Answer 1

[Станислав Макаров]

Вы столкнулись со стандартной задачей построения каталога - наборы характеристик для разнородных объектов, причём как я понимаю могут постоянно появляться новые типы объектов. Эта задача решается либо с помощью EAV, если оставаться в рамках реляционных баз, либо же путём хранения каталога в документной базе вроде MongoDB. Также рассмотрите вариант с использованием JSON/XML колонок в вашей РСУБД, если таковые поддерживаются.

Comments

[svilkov87]

У Вас явно больше опыта в этом вопросе, чем у меня) Скажите, а чем будет плох вариант с одной таблицей, в которой будут все необходимые поля для всех типов товаров?

[Станислав Макаров]

svilkov87 вариант с одной таблицей плох тем, что раз у вас будут значительные различия по полям между видами товаров, схема не будет выполнять свою основную задачу, и многие из/большинство полей будут NULL. В конце-концов вы запутаетесь, т.к. реляционная модель концептуально противоречит с таким подходом "разреженных" записей. Если выбирать между одной таблицей со всеми полями и несколькими таблицами, то вариант нескольких таблиц безусловно лучше.