> Вот JOIN'ы в часто выполняемых запросах - это зло.
т.е. "3 нормальная" и фактически любой справочник с атрибутами - зло. а плоская растущая "вширь" таблица (на каждый атрибут меняется структура) - добро.
???

> т.е. "3 нормальная" и фактически любой справочник с атрибутами
> - зло. а плоская растущая "вширь" таблица (на каждый атрибут
> меняется структура) - добро.???


Если атрибуты в справочнике известны заранее - никто не против.
Зачем JOIN'ы, кроме редких отчетов использовать - вот в чем вопрос.
Запросы должны хорошо индексироваться.

Я имею в виду три основных таблицы

1.Справочник - 2.таблица соответствия атрибутов справочнику - 3.Атрибуты (там еще справочник атрибутов, но это уже не важно).
Во 2-й таблице прописываются ID атрибута и ID справочника - все это работает влет при использовании индексов по ID во всех трех таблицах.

Или я что-то не так трактую. А насчет 3-й нормальной: при такой структуре, как я описал, должно быть меньше избыточных данных.

Так у тебя же тоже зло злостное.
Сплошные джойны по крайней мере трех таблиц.

Вообще-то да. При выборке дерева без них не обойтись...

Точнее, можно, обойтись. Но это вряд ли будет работать быстрее.

> при такой структуре, как я описал ...
промежуточная (2.таблица соответствия атрибутов справочнику) лишняя.

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

"Довольно часто встречаются приложения, построенные с использованием универсальных моделей данных для максимальной гибкости, и приложения, построенные так, что они мешают работе. Например, хорошо известно, что можно представить любой объект в базе данных используя только четыре таблицы:

create table objects (oid int pimary key, name varchar2(255));
create table attributes (attrid int primary key, attrname varchar2(255),
 datatype varchar2(25));
create table object_attributes (oid int, attrid int, value varchar2(4000),
 primary key (oid,attrid));
create table links (oid1 int, oid2 int, primary key (oid1, oid2));

Но как такая модель работает ? Простой запрос select first_name, last_name from person трансформируется в соединение трех таблиц с аггрегированием, более того, если имеются атрибуты NULLABLE - в таком случае может не быть строки в таблице object_attributes для некоторых атрибутов, - возможно, возникнет необходимость использовать внешнее соединение, которое может исключить оптимальные планы запросов из рассмотрения.

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

(с) Том Кайт "Эффективное проектирование приложений Oracle"

to Игорь Шевченко ©   (19.02.13 18:20) [46]:

> Те, кто применяет универсальный подход, загоняют себя в
> угол.

В неменьший угол загонят себя те, кто будет всегда применять специализированный подход. Подход надо применять соответствующий поставленной задаче. То есть на самом деле в угол загоняет не подход, а догматизм. Я это, кстати, в ответ ровно на эту же цитату как-то уже в потрепаловке писал.

За других ничего говорить не буду. Скажу за себя только. У нас везде применяется специализированный подход. Кроме одного места - каталог технических характеристик товаров. Там применена схема с атрибутами и значениями.

>vuk ©   (20.02.13 16:00) [47]
если не комм. тайна, можно узнать порядок кол-ва товаров и среднее кол-во характеристик по товару?

Товары - чуть меньше 200 тыс.
Характеристики товаров: общее количество записей- 1.3 млн, количество характеристик на товар - от 1 до 37

vuk ©   (20.02.13 16:00) [47]


> Я это, кстати, в ответ ровно на эту же цитату как-то уже
> в потрепаловке писал.


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

to Игорь Шевченко ©   (20.02.13 19:45) [50]:

> По-моему мы тогда пришли к общему знаменателю, что марксизм
> не догма, а руководство к действию.

Ну, в обчем-то, да. :)

>vuk ©   (20.02.13 19:37) [49]
на современном железе при порядке записей 10^6 EAV, конечно, взлетит

> на современном железе при порядке записей 10^6 EAV, конечно, взлетит
а чё нет, на "не современном"? при такой структуре максимум с чем придется работать 1 запись из товара (индексный поиск) + макс. 37 связанных с ней записей атрибутов (связь по индексу)... внутри 37 пусть даже множественным перебором много времени не займет. 286й под досом справится.

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

>sniknik ©   (21.02.13 10:56) [53]
взятие всех атрибутов по товару - это типовая операция, которая и на 10^9 взлетит - спору нет, индексы наше всё)
но есть ещё и другие типовые: например, поиск по значению нескольких характеристик с выводом найденных товаров и некоторых(всех) их характеристик
проблемы EAV начинаются именно отсюда

to Кщд   (21.02.13 12:06) [55]:

> например, поиск по значению нескольких характеристик

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


> с выводом найденных товаров и некоторых(всех) их характеристик

Как я уже говорил, практика показала, что вывод характеристик в строку оказался не нужен.

Если говорить именно о товарах, то на практике более актуальным является вывод таблиц сравнения характеристик, типа того: http://www.fcenter.ru/compare.shtml?108137,103642,106119,97418,107801

> Ашот ака Kaif, писал что что-то такое у него юзается.
> Вот мне с тез пор и интересно, как сделал.


С тех пор и маешься неудовлетворенным интересом ?
Allegro же как состоявшийся продукт давным-давно вполне доступна и для праздно любопытствующих и для готовых сделать на нее ставку в бизнесе ..

А сделал Ашот вполне по уму, imho поумнее чем в 1C

Позволю себе процитировать касающийся этой темы фрагмент документации разработчика на платформе Аллегро:


> Глава 7. СПРАВОЧНИКИ
>
> Классы, атрибуты, наследование
>
> Каждый регистр счетов привязан к одному справочнику объектов,
>  например , «Товары». Допустим, что мы автоматизируем работу
> компании, торгующей металлическими изделиями (винтами и
> т. п.) и обувью. Очевидно, что разные товары могут иметь
> разные атрибуты. Атрибутами винтов могут быть « Металл»,
>  «Диаметр» и «Длина». Атрибутами обуви - «Материал», «Изделие»,
>  «Размер », «Цвет» и «Вид». Кроме винтов , возможно, нам
> понадобится в справочниках хранить разные другие металлические
> изделия, характеризующиеся «Металлом» и «Наименованием ».
>  К тому же неплохо бы иметь в качестве общего атрибута «Внутренний
> номер объекта» (ID), чтобы использовать этот атрибут в других
> таблицах для ссылки на объекты справочной системы. С учетом
> сказанного, нам необходимы минимум три таблицы для хранения
> «Товаров»:
>
> «Обувь»
>
> ID  Материал  Изделие  Размер  Цвет  Вид
>                
>
> «Винты»
>
> ID  Металл  Диаметр  Длнна
>          
>
> «Разный крепеж»
>
> ID  Металл  Наименование
>        
>
> Как легко заметить, некоторые таблицы имеют общие по смыслу
> поля. Например, все три таблицы имеют поле ID . Винты и
> разный крепеж имеют общее поле «Металл ». Напрашивается
> мысль о том, чтобы хранить однородную информацию в одном
> месте, а не в разных таблицах. И действительно, если мы
> введем понятия «Товар вообще » и «Крепеж вообще», то задача
> намного упростится . Атрибут ID характеризует любой «Товар
> вообще», а атрибут «Металл» характеризует любой «Крепеж
> вообще». Можно даже сказать, что классы «Винты» и «Разный
> крепеж» наследуют атрибут «Металл» от класса «Крепеж вообще».
>  Что же у нас получилось ? Фактически это справочная система
> с некоторыми объектно-ориентированными свойствами. Все объекты
> у нас разделены на классы. Собственно, каждый конкретный
> справочник и есть класс. Классы образуют дерево с наследованием
> атрибутов старших классов младшими классами. Каждый класс,
>  таким образом, имеет собственные атрибуты и атрибуты, унаследованные
> от класса-предка. Каждому классу соответствует одна физическая
> таблица в базе данных, в этой таблице класс хранит только
> собственные атрибуты. Для полной сборки любого справочника
> наша программа автоматически производит объединение всех
> таблиц классов -предков с таблицей класса справочника по
> полю «Номер объекта» (ID).
>
> Например, если мы хотим создать классы «Товары», «Крепеж»,
>  «Винты», «Другой крепеж», «Обувь», то выглядит это примерно
> так:
>
>
> Таким образом, для строгого хранения данных, они разносятся
> по нескольким таблицам. И каждый объект одновременно хранится
> в разных таблицах. Часть атрибутов справочника «Винты» хранится
> в таблице класса «Крепеж». Поэтому для того, чтобы отобразить
> все атрибуты «винтов», как собственные, так и унаследованные
> от классов-предков, необходима « сборка данных» (по одной
> строке из разных таблиц ). Например, для сборки справочника
> «Винты» будут объединены таблицы: «Товары», «Крепеж» и «Винты»
> по полю ID. А для сборки справочника «Разный крепеж» будут
> объединены таблицы «Товары », «Крепеж», «Разный крепеж».
>
>
> К счастью, язык структурированных запросов SQL позволяет
> делать такие объединения таблиц достаточно быстро. Наша
> программа устроена так, что сборка справочников происходит
> автоматически путем генерации текстов SQL- запросов. Ничего
> программировать не нужно.
>
> Атрибутом класса может быть число, строка, дата, мемо-поле,
>  картинка или ссылка на объект другого класса. В приведенном
> нами примере, например, поля Материал, Изделие, Цвет и Вид
> в действительности следует организовать в виде ссылок на
> отдельные мелкие справочники:
>
> «Материалы для обуви»
>
> ID  Наименование
> 25  Кожа
> 27  Пластик
> 28  Резина
>
> «Обувные изделия»
>
> ID  Наименование
> 38  Сапоги
> 39  Кроссовки
> 40  Туфли
>
> «Цвета»
>
> ID  Наименование
> 95  Черн.
> 96  Коричн.
>
> «Виды обуви»
>
> ID  Наименование
> 70  Муж.
> 71  Жен.
>
> Итак, в реальности в таблице класса «Обувь» в основном хранятся
> ссылки:
>
> «Обувь»
>
> ID  Материал  Изделие  Размер  Цвет  Вид
> 487  25  38  37  95  71
> 511  25  40  37,5  96  71
>
> Разрешение ссылок (превращение ID в краткие наименования)
> программа осуществляет автоматически, присоединяя при сборке
> справочника еще и специальную таблицу наименований, так
> что пользователь видит нормальную таблицу, содержащую в
> колонках соответствующие названия, а не внутренние номера
> , которые реально хранятся в базе. Все объекты справочной
> системы имеют уникальные внутренние ID, которые поставляет
> генератор OBJECT _ID_GEN.
>
> Такая организация справочной системы позволяет одновременно
> решить ряд проблем:
>
>     Регистру счетов достаточно присвоить базовый класс какого-
> то дерева классов справочной системы и тот сможет работать
> одновременно со всеми объектами классов-потомков, какой
> бы атрибутикой те не обладали. А это означает для программиста,
>  конфигурирующего систему под задачу пользователя, возможность
> быстрого и корректного анализа бухгалтерских данных по любому
> атрибуту каждого отдельно взятого класса.
>
>     Декларативная ссылочная целостность (на основе ключей
> foreign keys) пронизывает всю систему ссылок и не позволяет,
>  с одной стороны, случайно удалить ни один объект, используемый
> в других справочниках или документах, а с другой стороны
> предельно повышает скорость объединения таблиц при сборке
> справочников. Важно и другое - сообщение о невозможности
> удаления объекта пользователь получает мгновенно .
>
>     Ссылочная природа справочников позволяет автоматически
> подчинять два справочника друг другу , для чего окно справочника
> делится пополам. В этом режиме в нижней части окна отображаются
> закладки всех справочников, которые могут быть подчинены
> справочнику, отображаемому в верхней части . Остается лишь
> выбрать нужную закладку. Например, перебирая «обувные изделия»,
>  можно тут же видеть всю обувь , отфильтрованную по данному
> признаку. Или, выбрав « Фирму», автоматически видеть все
> ее реквизиты. И все это без потери скорости, благодаря индексам.
>  
>
>     Всегда можно добавить новый атрибут в класс и его автоматически
> приобретут все объекты классов-потомков.
>
>     Способ хранения данных соответствует самым строгим требованиям
> теории реляционной баз данных (степень нормализации 3…5),
>  что значительно упрощает использование данных в SQL-запросах
> и повышает непротиворечивость хранимой информации и устойчивость
> данных к изменению структуры справочников.

> Сергей М. ©  

да, пожалуй что, надо скачать все-таки
тут надо почитать вдумчиво