Допустима ли такая архитектуры БД?

Question

[Demian1]

Comments

[di]

А цвет и размер товара не его атрибуты?

[Demian1]

di, его

[Demian1]

di, просто если все поместить в одну таблицу атрибутов, то это будет не очень красиво и удобно, потому что у одного товара: размеров 3-4, цветов ~5, картинок 5-6. По этому я решил так разбить, но не знаю, правильно ли это

[VicTHOR]

нейминг только хреновый, в остальном что надо

Answer 1

[d-sem]

Продукт вполне может входить в несколько категорий.

Аттрибуты (attributes) могут иметь значение - например, вес, присущий именно этому продукту. Поэтому многие ко многим тут не совсем очевидно. Хотя конечно можно это значение включать в промежуточную таблицу.

Размеры, цвет, как верно заметил di вполне себе тоже аттрибуты.

Comments

[Demian1]

а как тогда вписать все атрибуты в одну таблицу? через json?
id | size | color ...
1| {1, 2, 3} | {1, 2, 3}
2| 1, 2, 3} | {1, 2, 3}
3| {1, 2, 3} | {1, 2, 3}

Так?

[d-sem]

Demian1,
стандартный подход -
id атрибута, id родителя (для связи один ко многим), тип аттрибута(вес, цвет, все что угодно), его значение

[di]

Demian1, зависит от поставленной задачи. если клиенту надо вести статистику по проданным кроссовкам NIKE MODEL N1 45 размера красного цвета начнут возникать трудности.
Потому как NIKE MODEL N1 45 размера красного цвета это модификация товара NIKE MODEL N1

[d-sem]

Demian1, если хочется многие ко многим то что-то вроде такого https://www.codejava.net/frameworks/hibernate/hibe...

[d-sem]

Demian1, а с json полями начнутся проблемы когда надо будет оптимизировать фильтры по товарам или делать поиск по параметрам внутри этих json полей.

[tukreb]

d-sem, поэтому нужно выбрасывать недо СУБД MySQL и использовать PostgreSQL, где этих проблем нет.

[d-sem]

tukreb, т.е. Вы утверждаете, что в PostgreSQL поиск по Json полю, содержащем атрибуты будет эффективней, чем по отдельной таблице атрибутов?

[tukreb]

d-sem, да, есть даже замеры https://coussej.github.io/2016/01/14/Replacing-EAV...
у PostgreSQL просто нет конкурентов, я просто не понимаю, почему люди слепо используют одну из худших СУБД MySQL

[d-sem]

tukreb, мб потому что даже для такого синтетического примера прирост с индексами не слишком значителен, а набор кейсов ограничен.

1) в обратную сторону также хорошо работает?
2) а если добавить валидацию на тип полей - чтобы получать данные ожидаемых типов?
3) а в условиях кейса когда нужно получить только id сущности, где джоины не нужны?
4) для того чтобы получить список возможных значений какого то конкретного атрибута - нужно получать все сущности? Например, автокомплит для значений какого-либо атрибуты формы поиска интернет магазина.

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

[tukreb]

d-sem, насколько знаю, самый большой минус тут только обновление данных и разумеется контроль целостности.
Но если стоит выбор между EAV или JSON, когда с этим часто буду работать, то однозначно стоит выбирать JSON, он выиграет на длинной дистанции.

Answer 2

[BasiC2k]

Такая архитектура подойдёт, если у товаров ограниченное и небольшое число атрибутов
Если атрибутов много и все они разные, то можно для хранения использовать одну таблицу с полями:
1 ID атрибута
2 ID товара
3 название атрибута
4 значение атрибута

Дополнительно можно добавить поля:
5 Краткое (системное) название атрибута
6 Категория атрибута

Answer 3

[catanfa]

id у таблиц-связок не нужен, там уже есть первичный ключ в виде двух других айди.