Как построить структуру данных?

Question

[Pupochkin123]

Как построить структура данных (без JSONB)?

Products (id, title) - Товары
Features (id, title) - Характеристики
Props (id, title) - Свойства
FeatureProps (feature_id, prop_id) - Связь характеристики со свойствами
ProductProps (product_id, prop_id) - Связь товара со свойствами

Если будет изменено название свойства, как оно изменится во всех товарах соответственно, а если заменить точечно на определённых товарах? Или следует закрыть возможность изменения свойства на уровне логики в коде? Оставлять только добавление?

Comments

[mayton2019]

если я захочу заменить точечно на определённых товарах

Невозможно предугадать все твои хотелки в этом вопросе и сделать дизайн схемы так чтобы он всегда и всем был хорош. Ты должен перечислить все бизнес-кейсы которые возможны и дальше по ним проектировать.

А что будет если ты захочешь узнать кто производил товар до 2019 года? Нужна темпоральность? Добавлять дату-время к каждой строке каждой таблицы?

Answer 1

[Ипатьев]

Насколько схема корректная с точки зрения проектирования?

Непонятно, к чему здесь FeatureProps. Зачем тут многие ко многим?
ProductProps (product_id, feature_id, prop_id) достаточно

если я захочу заменить точечно на определённых товарах?

Скорее всего, это будет уже новое свойство.
Если захочется переименовать для отдельных товаров, то понадобится таблица feature_names(feature_id, product_id, name), которую лефт джойнить к запросу, и брать имя из неё, если есть.

Имена таблиц тоже лучше делать в нижнем регистре. Сбережёт некоторое количество нервных клеток.

На всякий случай предупрежу: Если продукт дойдёт до продакшена, то искать всё равно будете Эластиком. И как следствие - выкините весь EAV за ненадобностью, а все свойства сложите в JSON
Но для практики конечно поколупаться конечно полезно

Comments

[Akina]

это будет уже новое свойство

+100500

как следствие - выкините весь EAV за ненадобностью

о_О а где тут EAV?

[Ипатьев]

Akina, ну, автор ведь не первый вопрос задаёт про свой EAV
Ну и плюс насколько я вижу, это он и есть.

[mayton2019]

EAV, RDF - это такие обобщённые модели что их можно натягивать на что угодно. Да только недостатков они за собой тащут еще больше чем преимуществ. Вообще любая кастомная модель будет лучше EAV хотя-бы в плане простоты сопровождения и анализа ошибок и performance issues.

EAV любят теоретики и преподаватели которые читают лекции по SQL. В реальности, если вы пообщаетесь с инженерами DBA то услышите от них злобное шипение в адрес всех этих теоретических экспериментов. Поэтому лучше до последнего сохранять приверженность простой модели где таблица - это именно таблица с колонками которые несут смысл а не являются просто уровнями абстракций.

Кроме того активная поддержка JSON, XML и документов в БД сильно "размыла" начальные условия. Тоесть мы уже не пытаемся построить документы поверх атомов а мы уже просто можем ВСТАВИТЬ документ в ячейку и это реально работает. По крайней мере Oracle/MS это поддержали. Хотя это денормализация. Но всем пофиг.

[Akina]

Ипатьев,

насколько я вижу, это он и есть.

Не, вот совсем не оно. Элементарно таблица для EAV должна иметь ну как минимум три поля...

Тут обычный M:N.