Добрый день.

Проектирую БД. Вот, если коротко, небольшая часть:

Таблица: ТИП ТЕХНИКИ
-ID;
-Название;

Таблица: ПРОИЗВОДИТЕЛЬ ТЕХНИКИ
-ID
-Название;
-Договор;
-Дата заключения;

Таблица: ТЕХНИКА
-ID
-ID тип техники;
-ID производитель техники;
-Название;
-Дополнительное название;
-начальные буквы серии зав.номера;

Таблица: АТРИБУТЫ ТЕХНИКИ
-ID
-ID техника;
-Зав.номер;
-Версия;
-Дата изготовления;

Так вот, есть очень большая вероятность, что через какое-то время потребуется расширить кол-во полей для таблицы АТРИБУТЫ ТЕХНИКИ. Например: адрес установки, дата ввода в эксплуатацию и т.д. На этапе проектирования я не могу знать все эти нюансы. Более того, нет желания возвращаться к этому проекту спустя год и более.

Подскажите, как же правильно спроектировать, чтобы пользователь мог сам через какое-то время добавлять нужные ему поля. Может есть литература, статья или пример. Мне бы увидеть саму концепцию. Дальше сам разберусь.

Спасибо.

Таблица типов атрибутов, таблица атрибутов.

> чтобы пользователь мог сам через какое-то время добавлять нужные ему поля.
> Мне бы увидеть саму концепцию.
ставишь ему mssql + delphi ... готово.

Таблицы с неизвестным количеством полей

Заранее неизвестное количество атрибутов хранимой сущности вовсе не означает заранее неизвестное количество полей физической таблицы.
В первом посте тоже вариант не торт.
Это наверняка если не прямая дорога, то извилистая тропочка в ад.

Медвежонок Пятачок ©   (11.02.13 21:40) [3]

Что тогда торт? Есть примеры, литература?

> sniknik ©   (11.02.13 19:38) [2]
>
> > чтобы пользователь мог сам через какое-то время добавлять
> нужные ему поля.
> > Мне бы увидеть саму концепцию.
> ставишь ему mssql + delphi ... готово.
>

Или платная техподдержка. Имхо, самое лучшее решение.

>Цукор5   (12.02.13 00:35) [4]
>Что тогда торт? Есть примеры, литература?
по EAV есть на удивление неплохая статья на wiki.

>Кщд   (12.02.13 07:47) [6]
это к тому, почему EAV - не торт и тропинка в ад, в чём полностью солидарен с Медвежонок Пятачок ©

А давайте на примере [0]


> Таблица: АТРИБУТЫ ТЕХНИКИ
> -ID
> -ID техника;
> -Зав.номер;
> -Версия;
> -Дата изготовления;

> Так вот, есть очень большая вероятность, что через какое-
> то время потребуется расширить кол-во полей для таблицы
> АТРИБУТЫ ТЕХНИКИ. Например: адрес установки, дата ввода
> в эксплуатацию и т.д.

ну, сколько он там добавит?
ну, пусть, 20.

Почему бы не сделать ALTER TABLE? Да, тупо в плоскость.
+ Словарь таблиц.

При запуске считать словарь, понять сколько полей и где, модифицировать соотв. SQL.

С одним производителем может быть только один договор?

Толку от этих добавлений? Ну будут новые поля в таблице, пусть в гриде будут выводиться, пусть даже в форме всякие едиты и т.п. динамически добавяться. А дальше что?

Ну, также
Поиски/сортировки/группировки по добавленному
Только изначально надо писать запросы динамические
тестировать на том, что есть на сейчас

> модифицировать соотв. SQL.
не знаю как у вас, а у меня запросы соответствуют логике программы, объединения разные, группировки, и т.д. т.е. чтобы модифицировать, добавить обработку хотя бы одного поля, нужно думать... если же думать не нужно (бывает и так), значит ситуация формализуется, имеет что-то стандартное, что можно запрограммировать и не менять... парадокс однако.
ну вот к примеру этот справочник атрибутов. если он не четкий (количество плавающее) то почему он в плоской таблице? почему не сделать таблицу "заголовок" с не меняющимися параметрами (артикул - наименование - ...) и добавить к ней таблицу атрибутов "в высоту", с такой же жeсткой структурой - id - артикул (для связки) - наименование - значение... - количество атрибутов = сколько записей с требуемым артикулам. все. добавление атрибутов, любого количества, идет в рамках логики готовой программы... ничего добавлять/менять структуру не надо.  

> Только изначально надо писать запросы динамические
а чего мелочится то? динамические запросы... сразу динамическое программирование... т.е. ставишь дельфи... а, ну да, уже предлагал.

посмотрите на 1С, идея была та же, но ничего хорошего (в контексте темы, а не заработка на постоянной поддержке) не вышло. армия "не программистов" ходит по клиентам и меняет "спроектированное" в основных модулях.
думаете "на коленке" изобретете что то лучшее?

> думаете "на коленке" изобретете что то лучшее?

нет


> посмотрите на 1С, идея была та же, но ничего хорошего

именно, глядя на нее и думал.
Сам никогда еще так не делал. Но подозреваю, что трудностей до черта.

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

> Ашот ака Kaif, писал что что-то такое у него юзается.
у него gaap (небо и земля с нашей "упрощенкой") + паскаль скрип для "простого" изменения. т.е. то же самое программирование только непосредственно у клиента (тут аналогично 1С-у)

> Он же утверждал, что все работает быстро.
одно другому не мешает. тут "быстро" вообще не по теме (не критерий в топике с лирическим переводом - "сделать так, чтобы настраивалось то, что обычно программируется").

> ну вот к примеру этот справочник атрибутов. если он не четкий
> (количество плавающее) то почему он в плоской таблице? почему
> не сделать таблицу "заголовок" с не меняющимися параметрами
> (артикул - наименование - ...) и добавить к ней таблицу
> атрибутов "в высоту", с такой же жeсткой структурой - id
> - артикул (для связки) - наименование - значение... - количество
> атрибутов = сколько записей с требуемым артикулам. все.
> добавление атрибутов, любого количества, идет в рамках логики
> готовой программы... ничего добавлять/менять структуру не
> надо.  


А можно подробнее. Ничего толком не понял.

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

> Ничего толком не понял.
придет со временем... или не придет.

А зачем они, эти дополнительные атрибуты, нужны будут в дальнейшем ?

2 Игорь Шевченко ©   (12.02.13 14:14) [16]
Да, нужны. Вам пример из жизни?

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

> [17] Цукор5   (12.02.13 14:19)
> Вам пример из жизни?

Хотелось бы.

> Да, нужны


С какой целью ?

С целью ведения учета в связи с новыми обстоятельствами (я про новые атрибуты). Вторая задача: не переделывать структуру БД , т.к. нет желания возращаться к этому проекту спустя какое-то время.

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

Прошел год. Государство решило ввести новую норму закона и каждому аппарату присвоили фискальный номер. Более того, заказчик теперь обязан во всех документах указывать этот фискальный номер.

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

И так примерно каждый год. Что-то отменяется, что-то добавляется.

> > Он же утверждал, что все работает быстро.
> одно другому не мешает. тут "быстро" вообще не по теме

по теме

Идет запрос на определение, разбор что там есть, генерация нового SQL на основании "метаданных"
Это долго.
Например, как в 1с, вводим новую таблицу, специально под конкретную группу товаров, со своими хар-ками
user все задает и мы делаем Create table

Потом, запросами к метаданным, получаем эту таблицу, имеем  поля, их типы, ссылки FK|PK таблицы
(ну, что бы в гриде можно по клику на поле еще грид показать, с соотв. таблицей, на которую ссылается, и т.п.)

Например, на опредление структуры одной таблицы (Oracle)



работает примерно 8-10 секунд
получим
EQUIPMENT EQUIPMENT_TYPE_ID NUMBER(22)NOTNULL "Тип оборудования."
EQUIPMENT EQUIPMENT_TYPE_ID EQUIPMENT_TYPE ID
теперь можно в гриде по клику на поле, еще грид показать, с соотв. таблицей, на которую ссылается, откуда можно выбрать значение или вставить новое, при этом  можно по клику на поле, еще грид показать, с соотв. таблицей, на которую ссылается
ну и  так далее.

т.е. заранее иерархия справочников не известна. И юзер теоретически ее может сам посторить.
И ее надо вычислять по мере продвижения

ps
еще раз - сам не пробовал. Просто думаю.

Что мешает все эти нововведения хранить в одном месте, не по-атрибутно ?
Я спросил, какая цель именно в необходимости добавления отдельных атрибутов, полей, таблиц и т.п.

Сегодня это один фискальный номер, а завтра это переменное количество номеров для одной единицы техники в зависимости от фазы луны при ее изготовлении или покупке.

Если хочется сделать одно приложение для всех грядущих отчетов на все возможные случаи жизни, это, по-моему, утопия. Если хочется добавить возможность пользователю самостоятельно конструировать новые формы отчетов по мере изменения внешних обстоятельств, то зачем ему вообще какое-то приложение ? excel и access вполне достаточно

> Что мешает все эти нововведения хранить в одном месте, не по-атрибутно ?
+
судя по описанному [20] никаких обработок, поисков, фильтраций т.е. работы с данными не предполагается, т.е. мемо поля хватит на все. т.е. без смены структуры. в отчетах мемо поле легко отображается.
условия соблюдены.

> генерация нового SQL на основании "метаданных"
> Это долго.
у Ашота этого нет, ... ну, не нужно по крайней мере. в скрипте структура также известна и также не требует "на основании" как при обычном программировании.

p.s. чето через чур "8-10 секунд"? mssql + схемы ado структуру мгновенно определяют. может с миллисекундами спутал?

> [20] Цукор5   (12.02.13 15:06)
> во всех документах указывать этот фискальный номер

> [20] Цукор5   (12.02.13 15:06)
> И опять во всех справках и отчетах эти новые атрибуты.

> [20] Цукор5   (12.02.13 15:06)
> И так примерно каждый год. Что-то отменяется, что-то добавляется.

Кто всё это будет переделывать?

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


Еще как предполагается.


> Кто всё это будет переделывать?


Я, например.

Вероятно, я плохо объяснил. Пардон. Идея в том, чтобы каждый раз при появлении новых атрибутов не править базу(добавлять/изменять/удалять таблицы или некоторые поля таблиц). Естественно, при появлении новых атрибутов возникнет необходимость делать формы, запросы, отчеты и т.д. Это я понимаю и готов к этому. Повторюсь, хочу лишь определиться со структурой базы, чтобы можно было не заглядывать туда лет 10.

Извините, если плохо объяснил.

> у Ашота этого нет

да?!
Блин, тогда как же он спроектировал так ловко..
зы. Скачать что ли уже, посмотреть  :)


> p.s. чето через чур "8-10 секунд"?

да, именно секунд.
А и говорят, что MSSQL лучше мета поддерживает.

Возможно, не оптимально написал и можно как-то иначе.
Возможно, >> говорят, что MSSQL лучше мета поддерживает
именно такие же

Просто мне пока для анализа хватает.
ps
Хочу написать свой построитель схем БД :)
Как в MSSQL.
Сколько искал - не то все. Тоад не нравится(нравится, но он "рисует не правильно:)" ), PLSQL - тоже.

Хочу написать простую для юзания программку, аля запустил, имя схемы вбил, пошел курить. Пришел - все построено (и отображается как в MSSQL !)

> [26] Цукор5   (12.02.13 17:04)
> Я, например.

Тогда сабж блажь.

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

> а кто-то наоборот все на sql процедурах пытается, типа,
> "шоб после программу не пере-компилировать на каждый чих". и тоже блажь.
А что тут-то не так? :)

2 Inovet ©   (12.02.13 17:13) [28]

Что тогда не блажь? Как бы Вы сделали?

> [31] Цукор5   (12.02.13 18:03)
> Как бы Вы сделали?

Изменял структуру базы и приложение в соответсвии с новыми требованиями. Для перевода базы на новую версию достаточно выполнить SQL скрипт, например.

> А что тут-то не так? :)
всегда... т.е. нет не так, не всегда, а ВСЕГДА заказ на изменения идет от клиента... т.е. так, что не собралась кучка прогеров и решила "а давайте ка вот эту процедурку поменяем, так чтобы внутри все по новому, а наружу как было", нет, такого не бывает, всегда бух/кассир/агент/... говорят "а вот тут пола/данных не хватает, отчет нужен по другому/группировка по новому", что тут же делает не действительным возврат какой то процедуры - итог правка в двух местах, причем с осложнениями т.к. -
а) "а может кто эту процедуру использует, не только мы... давайте на всякий случай сделаем в копии... ".  
б) "ну уж теперь нужно все предусмотреть... сделать реально универсально... давайте передавать строкой и там парсить" (или любой другой аналогичный бред по сути)
есть реально старые базы в обслуживании? проверь на предмет копий процедур. поинтересуйся идеологией проектирования (если есть еще у кого, т.к. частенько когда начинается подобное автор сбегает на новое место, со старыми идеями)

> sniknik ©   (12.02.13 19:57) [33]
у нас и переделка отчета не ведет к перекомпилированию. ;)
вернее так: если это не касается интерфейса диалога с пользователем (или чегото подобного) то перекомпилировать не надо, иначе никуда не деться.
Ну так это и есть - "по любому чиху".
А вот когда приходится перекомпилировать без особой на то необходимости, а просто потому что все в ехе, вот тут действительно "руки страдают"... :)

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

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

>у нас и переделка отчета не ведет к перекомпилированию. ;)
открыли для себя фастрепорт? забыли нужные поля из рекордсета сразу включить? включили потом ... речь вообще была об этом, а том что данных нет. раз нет в отчете (заметили там) то и в возвращающей процедуре (иначе смысл ее менять, на меняя как желается программу? просто показать/похвастаться возможностью?).

> без особой на то необходимости
я про то и говорил, она есть ВСЕГДА. т.к. причина всегда клиент (не, я конечно слышал, что где то там, есть что то, что не всегда... воспринимается как миф, без подтверждений в жизни). вот ты тут тоже сказки рассказывать пытаешься.

> а просто потому что все в ехе, вот тут действительно "руки страдают"... :)
???
чем плохо когда все в одном месте? логика/централизация... когда настройки в одним месте это хорошо, когда сервер/база в одном месте (логически) это хорошо, права в одном месте настраиваются (актив деректори) тоже хорошо, а вот если в exe, то руки страдают? бредишь небось?

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

Элементарно. Посмотри, как этот вопрос решен, например, в DocsVision

А как смотреть? Продукт не бесплатный:
http://www.docsvision.com.ua/costs/

Выдержка с другого форума:"Ничего плохого в EAV нет. Если под текущий размер базы выделены достаточные аппаратные ресурсы и в базе в нормальном виде расставлены индексы, то самым тормозным местом будет явно не база. Так что «советчиков» которые без конкретных аргументов так говорят можно сразу спокойно слать лесом.".
Полностью согласен с этой точкой зрения.
Никто структуру/запрос EAV не приводит для примера, а на самом деле там все просто. Если надо набросать примерную схему - нет проблем.
Интерфейсная часть решается через древовидный список, как здесь уже писалось. Есть заковыка с типами атрибутов, но это тоже достаточно просто решается (есть, по крайней мере 3 способа).
А каждый раз таблицы менять - это крайне неудобно и требует лишних усилий.
Вот JOIN'ы в часто выполняемых запросах - это зло.

> [38] IronFox ©   (19.02.13 10:15)

Да ради бога, усложняй себе жизнь, кто же против.

> Вот 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-запросах
> и повышает непротиворечивость хранимой информации и устойчивость
> данных к изменению структуры справочников.

> Сергей М. ©  

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

>vuk ©   (21.02.13 12:29) [56]

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

Если по одному полю, значит, у вас значения характеристик нетипизированы. Но даже в этом случае любой чуть сложный предикат(напр., Характеристика1="А" или Характеристика2>3 и Характеристика3 между sysdate - 1 and sysdate) может стать причиной full table scan таблицы значений характеристик. Я говорил именно об этом.

>Как я уже говорил, практика показала, что вывод характеристик в строку оказался не нужен.
Это особенности Вашей системы.

to Кщд   (21.02.13 17:42) [60]:

> Если по одному полю, значит, у вас значения характеристик
> нетипизированы.

Совершенно верно. Там вообще везде текст и никаких поисковых запросов в виде выражений SQL пользователи никогда не пишут. Тут при поиске более полезен полнотекстовый поиск.


> Это особенности Вашей системы.

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

>vuk ©   (21.02.13 18:15) [61]
>а вы опять пытаетесь придумать
я говорил об общих проблемах EAV(реальных, а не придуманных), а не Вашей системы, о которой мне неизвестно ровным счетом ничего)
мы друг друга не так поняли

самый простой вариант- писать тэгами в поле типа мемо

>Дмитрий   (16.04.13 20:32) [63]
)))

Я в свое время для аналогичных задач использовал несколько различных способов, в зависимости от задачи.

1. Добавление таблицы для атрибутов
2. Возможность делать ALTER TABLE прямо из программы, создавая свойства динамически через DB-GRID
3. Использовал мастера шаблонов, где под каждый шаблон создается отдельная таблица, буквально в 2-3 клика пользователь может сам создать любой шаблон

>Akella-M   (30.04.13 16:17) [65]
все вменяемые варианты разобрали с нюансами и примерами
не читатель?