eugeneТак для типа Электродвигатель основные подтипы -постоянного-переменного тока. Для переменного тока -следующий уровень-синхронный-асинхронный
Кроме того желательно отразить в БД не одну а несколько классификаций, причем разных для каждого типа устройства.
https://habr.com/post/254773/
читайте, практикуйтесь
пока до конца не поймёте хотя бы первые 3 формы, дальше не суйтесь

ну, поговоривают, что магенто перешло на flat tables (в списке толи 1, толи 3), сам правда не видел, не пользуюсь
альтернатива в том плане, что это всё ещё таблицы
я сам то предпочитаю всё что можно в редиске хранить

hVostttip78я сам то предпочитаю всё что можно в редиске хранить

сложные отчёты по редиске делали когда-нибудь? всёж инструмент надо выбирать не по принципу "предпочитаю", а исходя из задач и требований.
10 таблиц с фильтрами это сложные ?
такое проще агрегировать, по возможности (а она практически всегда есть)
редис он больше для внешнего мира нужен, а отчётность это скорее внутри, в CRM

ПомидорL_argoпропущено...
+500. Все 4 практически непригодны для реальных условий.

Что скажете на это?! http://coussej.github.io/2016/01/14/Replacing-EAV-with-JSONB-in-PostgreSQL/

авторReplacing EAV with JSONB in PostgreSQL
дальше можно не читать.
JSONB никогда не заменит EAV, хотя бы потому, что там индексы много хуже работают. И сложный поиск там вообще труба.
И не GiN, ни jsonb_path_ops, ни jsquery тут не помогут. Производительность падает и запросы становятся сложнее.
Jsonb_path_ops хоть и быстрее монги, но он узконаправленный для очень простых случаев.
Вот что сами разрабы пишут:
авторНедостаток класса jsonb_path_ops заключается в том, что он не учитывает в индексе структуры JSON, не содержащие никаких значений {"a": {}}. Для поиска по документам, содержащих такие структуры, потребуется выполнить полное сканирование индекса, что довольно долго, поэтому jsonb_path_ops не очень подходит для приложений, часто выполняющих такие запросы.
Таблица, где ID + json CREATE TABLE bad_tbl(id serial,json json) = НЕправильная таблица.

В 11 придёт jsonB dictionary compression (jsonbc), вместе с SQL/JSON, но я всё-равно сомневаюсь, что он полностью заменит реляционную алгебру.

Ну а сейчас, если по данным производится поиск/выборки/JOIN-ы/итд, то это отдельные колонки. JSONB нужен, чтобы хранить простыню данных о юзере, которые второго плана и редко достаются.
Если туда редкие запросы, то GiN-индекс тащит, а если кол-во запросов растёт, то в отдельную колонку.

90 полезных слайдов про JSON

* Таблица, где ID + json b CREATE TABLE bad_tbl(id serial,json json b ) = НЕправильная таблица.

Помидор, берите любой многоуровневый JSON и считайте скорость
lvl1 => [
lvl2 => [key21 => val21, key22 => [
lvl3 => [key31 => val31, key 32 => [
lvl4 => [key41 => val41]
]]]

вот наделайте таких миллион строк и тестируйте поиск val31, val41.
ну или https://postgrespro.ru/docs/postgrespro/10/datatype-json#JSON-INDEXING]почитайте внимательно доки
и послушайте Бартунова перед сном:

Кот Матроскин, а это что по-вашему?

ну и далее, соот-но: WHERE t3.a = x AND t4.b = y

Кот Матроскинtip78Кот Матроскин, а это что по-вашему?

Какой-то незаконченный запрос непонятно чего :) может сойти в качестве примера "как не надо называть объекты в БД".

Я спросил структуру EAV (т.е., грубо говоря, какие сущности с какими атрибутами Вы планируете в ней хранить).


как это "непонятно чего"? Обычная отчётность захватывает кучу таблиц и требует их фильтрации.
Поиск свойств товаров.
Любые случаи, которые не решаются простым "overlaps".

авторИ почему-то мне кажется, что в JSON-ах, хранящих эти атрибуты для каждой сущности, вполне можно будет обойтись одним уровнем.
я не пойму, вы никогда не видели многоуровневые JSON-ы?
Берёте любой и ищите значение из последней группы, а потом сравниваете с поиском в отдельных колонках.

SERG1257tip78 Кот Матроскин, а это что по-вашему?А это сбор одной строки. Достать одну строку с BLOB (а это можеть быть хоть JSON хоть XML) в разы быстрее чем в EAV. И вероятность накосячить у EAV выше.
не достать. НАЙТИ! В последней ветке.

Кот Матроскинtip78пропущено...


как это "непонятно чего"? Обычная отчётность захватывает кучу таблиц и требует их фильтрации.

Я еще раз напоминаю, что Вы собрались сравнивать EAV . Так что давайте будем смотреть запрос сущностей, лежащих в EAV, и по атрибутам, тоже лежащим в EAV.
ну так разложите дерево JSON по таблицам и сравнивайте. Я про это говорю уже 3й пост.
Или откройте видео на 25:00 и послушайте минуту самих разработчиков.
Кстати, hVostt напомнил ещё один важный момент - даже цифры там являются текстом. Т.е. скорость поиска падает уже даже на этом простом факте.

кстати, на 29й минуте он рассказывает про jsonpath, а на 31й про ф-ю JSON_TABLE()
оба нововведения выйдут в 11й версии
'jsonpath' -- позволяет указывать путь поиска внутри дерева. Крутой бафф индексов.
JSON_TABLE() -- позволяет представить JSON-tree в виде таблицы. Делать с ней JOIN и т.д.

Т.е. мы получим EAV через JSON. На-ко-нец-то.
Вопрос - "а нах*й оно нам надо?", это отдельный вопрос.
Искать по глубокому дереву всё ещё будет медленнее, чем в обычном EAV. Разве что только по верхней ветке будет более-менее быстро.
Но с отдельными колонками думаю всё-равно не сравнить.

hVosttНа самом деле JSONB действительно лучше, чем EAV
hVosttНо это не EAV, не является её альтернативой, и не решает задач так, как их решает EAV.
и как это вам удалось собрать 2 этих утверждения в одном сообщении? )
Тут либо оно лучше и заменяет, либо оно само по себе и лучше "самого себя", а EAV это таки другое.
Взаимоисключающие_параграфы

на самом деле, после выхода jsquery, json_path_ops и селективных индексов (когда индекс не на всё дерево, а только на нужные ключи, что делает его в разы меньше и быстрее) - можно перетестировать различные паттерны.
Но не такие примитивные, как в статье, где поиск только по верхнему ключу, а что-то посерьёзней, типа сложной отчётности, категорий, свойств итд.
Я вот когда пробовал заменить свои задачи на JSONB в итоге плюнул.

GIN jsonb_path_ops порвал монгу и все остальные индексы.
(в статье его даже не юзали, как и jsquery)
Ещё они планируют таки добавить (толи тип, толи функцию) datetime(), которая сможет управлять таймстампами в JSONB... Т.е. одним недостатком меньше.

Но мой тезис был не о том, что JSONB ни на что не годится. Речь то не про то.
Он рулит в своей нише, но эта ниша не может полностью заменить EAV, просто потому, что нет полноценной замены плюшек EAV. Нет релятивисткого "сахара". FK нет.
И потом, когда достаёшь это счастье в ПХП, тебе на каждой строчке надо делать json_decode(), что при 100 строках уже чувствуется.

Когда надо сложить в кучу много второстепенной инфы, то да, там можно всё скинуть в jsonb, но если там надо будет искать глубоко по дереву, то до появления jsquery это было очень проблематично и затратно.
Но даже сейчас, если фильтр будет сложным, результат может не понравиться.
В 11й может будет лучше. А может нет.