SiemarglОсновная таблица - товар, дополнительная - атрибуты товара
не ОК
Скажем так, утверждение о том, что при прочих равных некий набор информации "начнёт загибаться" в таком формате и "не начнёт загибаться" в EAV для меня выглядит... сомнительным.

SiemarglНе очень понял. Пример, что в магазин завезли вибраторы, и нужны новая категория и набор атрибутов
Попробую сформулировать. Я не то чтобы серьёзно отношусь к требованию непрерывного онлайна, по моему опыту, для тех задач, для которых требуются кастомные атрибуты, оно нехарактерно. Тем не менее, я уверен, что если мне выставят подобные требования - я как минимум для Oracle смогу предложить тот или иной приемлемый вариант на основе этого подхода. Думаю, это справедливо не только для Oracle.

SiemarglНу это для практики поиска по атрибутам нерабочий вариант.
Отнюдь. Зависит от возможностей индексации конкретной СУБД. Наверное, какие-то этого не умеют - но я не стал бы из-за этого называть вариант нерабочим. Тем более что он обладает ценимой Вами максимальной онлайновостью.

SiemarglДа и НФ0, для блокнотика
Не совсем так. Понятие нормальных форм опирается на понятие атомарности хранимого значения. Само понятие атомарности, если над ним задуматься, специфицировано весьма размыто. Ну например поле даты - оно ведь состоит из дня, месяца, года. Или строковое поле, которое состоит из кучи символов. Какие же это атомарные значения и что такое вообще атомарность?

Если подумать над этим, становится очевидным следующее: значение является атомарным тогда и только тогда, когда оно "целым" участвует в операциях бизнес-логики (как минимум в явном большинстве таких операций). Вот у нас есть строковое поле. Если мы делаем с ним такие операции как "прочитать" (целиком), "записать" (целиком), "сконкатенировать с другими" (целиком) - это атомарные значения. Если же мы только и делаем, что "берём первый символ", "берём со второго по пятый символы" и т. п. - значение неатомарно и, соответственно, дизайн нарушает требования 1НФ.

Почему я говорю про большинство операций - потому что даже с "вроде бы атомарными" значениями иногда надо выделять части. Скажем, иногда мне нужно взять из лога записи, о том, что случалось с третьего по пятое сентября с девяти до десяти утра - но это не повод объявлять, что datetime поле нарушает 1НФ. Или - ИНН вроде бы вполне себе атомарное значение, мало кто будет хранить его по частям, но его первые цифры дают номер налоговой инспекции, да и контрольный разряд надо вычислять.

И это приводит к разумному и практичному выводу: на самом деле "атомарный" - неудачный термин для этого случая (как он в итоге оказался неудачным и для атома, который, как выяснилось, очень даже делим). Понятие атомарности используется по историческим причинам, но то, что в самом деле следовало бы поставить на его место, имеет смысл наподобие "удобно в использовании". Если нам приходится всё время строковыми операциями выщемлять значения из списка через запятую - это неудобно, нарушение 1НФ. Если для выделения, например, месяца из даты есть удобный синтаксис extract - нет проблем, поле даты не нарушает 1НФ даже если кое-где такое выделение происходит. И здесь стоит вспомнить, что понятие атомарности вводилось в те времена, когда в БД не было не то что хранимых процедур, а вообще каких-либо функций.

Ну так вот, смысл всей этой портянки в том, что подобное поле "коллекция дополнительных атрибутов" - значение, с которым вполне удобно работать. Главные операции с ним - выдать в интерфейс, получить из интерфейса, отфильтровать по значению какого-либо атрибута - выполняются вполне легко и эффективно. Так что не проблема.

drynnyЭта штука называется построитель запросов . Так она выглядит в базовом интерфейсе, но также у неё есть более дружественные пользователю воплощения.
Я ожидал такого ответа. В общем, неважно, как она выглядит - важно то, что её необходимо использовать и у неё нет альтернативы. Напомню, речь в этом фрагменте шла про "удовольствие построения отчётов". Так вот, получается, что при этом подходе практически недоступно подавляющее большинство инструментов построения отчётов, существующих в мире. Годится только один - тот, который написали Вы. И либо Вы заявите, что он самый лучший, умеет абсолютно всё и для любой задачи годится лучше, чем другие существующие построители - либо мой тезис про то, что такой подход делает построение отчётов хуже и неудобнее, доказан.

drynnyОбратите внимание, что я не лезу в EAV, не задумываюсь как строить запрос: я просто перечислил нужные колонки и добавил функции, фильтры и формулы.
Это важно для чайников. Более-менее приличный профессионал пишет запрос руками куда быстрее, чем он нащёлкивается в подобном построителе, ну и кроме того я на 99.9% уверен, что если взять, допустим, отчёты из того проекта, над которым я сейчас работаю, окажется, что Ваш построитель не в состоянии реализовать ни один из них - просто интерфейс не позволит сформулировать соответствующий запрос.

drynnyЧто-то с формулой я накосячил второпях, но не в этом суть
Суть, конечно, не в этом, но деталь показательная. Думаю, если Вы попытаетесь написать этот запрос руками на SQL над обычной реляционной таблицей - не ошибётесь даже с первого раза. Довольно наглядное сравнение сложности.

drynnyДа, рискну заявить, что сам подход достаточно прост для постижения, поэтому написать свой построитель будет заметно легче, чем любой из существующих построителей.

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