Как решить проблему типов при отношении многие ко многим?

Question

[hrvasiliy]

На скриншоте представлен пример связи многие ко многим. У товаров могут быть разные параметры, а у параметров могут быть разные товары.



Не могу разобраться, как решить проблему типов, если в таблице options поле value может быть разных типов? Например, у меня появляется запись, где value TEXT(2000), соответственно, это поле не влезет в текущий VARCHAR(255).

Единственное, что пришло в голову, сделать отдельную таблицу с полями product_id (INT), value (TEXT). Но что-то не особо мне нравится такое решение.

Кто-нибудь сталкивался с подобными проблемами?

Answer 1

[eRKa]

Все зависит от того как Вы этот value собираетесь использовать.

Если не нужно будет по нему делать поиск, индексировать, то можно сделать MAX, и в нем же хранить тип значения, что-то вроде {"$type":"int","value":3}

Если по нему все же надо будет делать выборку, то я бы, наверное, сделал таблицу value с полями для всех возможно нужных типов и в options сделал два поля type и valueId ну и тогда я буду знать строку и колонку, где читать значение в таблице value.

Comments

[hrvasiliy]

Что касается 1-го варианта: Плохо получается, по причине того, что все поля будут слишком "тяжелые". Или я не прав? Например тип данных JSON или TEXT не фиксированной длины? То есть

{"$type":"int","value":3}

и

{"$type":"text","value":"some text"}

Будут занимать разное кол-во памяти или фиксированное как CHAR?

Про 2-й вариант думал, только в виде отдельных таблиц для каждого типа.

[eRKa]

hrvasiliy, char будет всегда фиксированной длинны, не зависимо от того, какого размера будет строка, а вот varchar, даже если объявишь 255, а положишь туда строку 10 символов, то занимать она будет 11 байт, при условии, что кодировка однобайтовая (lat1), ну если двубайтная, то будет 21 байт занимать.

В общем, если Вы не собираетесь хранить в value тексты неопределенного размера, то делаете varchar(2000) например и в памяти будет занимать место длина + 1 байт. char имеет место, когда значения одинаковой длины (идентификаторы, флаги), Вы сэкономите на памяти по 1 байту с значения, но быстрее он не будет по сравнению с varchar. Но вот varchar будет побыстрее, чем text из-за тог, что varchar в таблице хранится, а text хранится снаружи и в таблице только ссылка на место хранения.

Answer 2

[Dmitry MiksIr]

• У вас неверный EAV. Value должно быть в product_option, иначе нарушается нормальная форма.
  
• EAV вообще так себе паттерн, его даже часто называют анти-паттерном, и не только из-за проблем с типами, но и из-за проблем с фильтрацией по нескольким условиям.
  
• Типы в EAV решают кто во что горазд. Кто-то отдельными таблицами, кто-то отдельным полем с указанием типа (и большой varchar value), кто-то просто текстом.
  

Советую посмотреть вот эти слайды
https://www.slideshare.net/billkarwin/practical-ob...
https://www.slideshare.net/billkarwin/sql-antipatt...

Comments

[hrvasiliy]

Если value будет в product_option то не получится связи один ко многим, что приведет к дублированию записей в таблице.

[Dmitry MiksIr]

Записей в product_option у вас и так больше одной будет на товар. А в вашей схеме получается еще и дублирование названий опций. Прочитайте про EAV.