Привет.
Допустим, есть небольшое кафе или ресторанчик, предлагающее определенные товары посетителям.
И у разных категорий товаров есть некоторые специфичные параметры..

Для спиртных напитков предполагается использование следующих полей в таблице item:

item_volume // объем, мл
item_percent // крепость
item_vendor // производитель
item_origin // страна происхождения

Для, например, блюд поля будут примерно следующими:

item_name // название
item_weight // вес
item_contains // состав
item_type // первое блюдо, второе блюдо \ десерт

Ну и далее.. Сигареты, какая-нибудь газировка..

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

Меня интересует, как логически организовать таблицу товаров?
Все товары должны присутствовать в одной таблице, а их свойства (поля таблицы) будут смешаны (т.е. будет одна большая таблица item со свойствами всех товаров, большая часть из которых будет заполнена NULL'ом (или нулями, или еще чем-то?) )?

Или под логически разные категории товаров лучше создать отдельные таблицы? Тогда в таблице заказов будет бардачок - на каждую таблицу товаров ( на вино, на блюда, на сигареты и прочее ) надо будет сделать внешний ключ. И в каждом кортеже лишь один из них будет заполнен, остальные будут NULL ).

Как смешать несмешиваемое? :)

Таблицы и параметры я привел для примера, чтобы была понятна суть вопроса. Буду благодарен ответам (можно в общих чертах, а конкретизировать под свою БД я уже попытаюсь самостоятельно).

Было да сплыло.. Или я пропустил что-то, или та ветка застряла также, как и эта.

авторВариант 1: разреженная таблица;
Вариант 2: EAV;
Вариант 3: сериализованное (напр. в JSON) поле свойств.

1. Не нашел внятного объяснения разреженной таблицы. Эта таблица, в которой перечислены все свойства всех возможных товаров, при использовании которой большая часть свойств будет заполнена NULL'ами или нулями, а оставшаяся малая часть свойств, принадлежащих тому или иному товару, будет заполняться полезными значениями ?

2. Про EAV так и не смог вкурить.. Русских статей мало или я поленился детально вникнуть в этот вопрос. Набросок схемы представлен ниже.

3. Вариант интересный с JSON, но со свойствами надо работать (считать количество товаров в наличии, например, объем всех спиртных напитков).

________

Теперь про EAV или то, что получилось.
На моей картинке ниже есть центральная таблица goods, в которой перечисляются товары. Внешним ключом к ней служит ID категории товара из соседней таблицы справа. В свою очередь таблица категорий "раздает" свой внешний ключ на соседнюю таблицу параметров категории товара через связь один-ко-многим.

Примерно так:
Категория drinks - параметры volume, strenght ( крепость ), made_in, ...
Категория eatable - параметры weight, cooked_time ( время приготовления ), contains ( состав ) и пр.
Категория cigarettes - параметры brand_name, is_lights, country_origin и пр.

Есть корзина cart, которая соединяет used_id и goods_id, т.е. пользователя и выбранные этим пользователем товары.
Есть таблица заказов order с промежуточной таблицей order_contains, в которой перечислены включенные в заказ товары.

Осталось понять, как реализовать связь между товарами и свойствами категории, к которой этот товар принадлежит. Камень преткновения :) Есть идеи дальнейшего строительства таблиц?

Что такое FLAT TABLE ? Кто-либо работал, сталкивался? Можете объяснить своими словами?

нашел, правда, не сразу..
Это тот же вариант с JSON, только в профиль..

автор Definition - What does Flat Database mean?

A flat database is a simple database system in which each database is represented as a single table in which all of the records are stored as single rows of data, which are separated by delimiters such as tabs or commas. The table is usually stored and physically represented as a simple text file.
https://www.techopedia.com/definition/25330/flat-database

Судя по всему, в рамках реляционной модели решить вопрос невозможно..
В любом варианта будет бардак с точки зрения "нормальности" БД.

sparsed table, она же "таблица, заполненная "null'-ами. Хранит массу пустых ключей и полей, в которые могут быть внесены ошибочные данные. С точки зрения логики этот вариант хромой, т.к. таблица содержит взаимоисключающие поля (например, крепость напитка и .. там.. не знаю... количество сигарет в пачке).

JSON-формат свойств товаров : по свойствам нужно пробегаться, работать с ними - сортировать по производителю, например.

EAV-модель: также не обеспечивает целостность данных. Таблица товаров - таблица свойств - таблица значений свойств. Но как быть, когда есть таблица производителей, например. Таблица значений свойств ( Value ) должна иметь внешний ключ из таблицы производителей, да и из других таблиц (как иначе обеспечить целостность? Вбить всех производителей в ENUM? А если товар, в отличие от большинства других товаров, не содержит данных о производителе? Например, это услуга какая-то).
Это уже дает бардак, приходим к пункту 1 - sparsed table

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

flat table - не удалось найти понятную информацию.. Но судя по той, что попадалась - этот вариант похож на использование JSON-сериализованных данных.

Не устраивает ни один из этих вариантов.

все это - одни костыли.. я разочарован, узнав, что такой типичный бытовой кейс не решается средствами sql без извращений