On 11.10.2010 12:18, OLEG_2005 wrote:

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

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

Если все атрибуты известны на момент реализации, то EAV как бы не обязательно.
Или если готовы согласится на (постоянную) дополнительную работу программистов.

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

Время ещё одного JOIN-а таблицы -- это O( log(N) )
где N -- общее число атрибутов всех сущностей.
(предполагается, что для JOIN-а используется индекс,
а иначе это безумие).

Соответственно, время вывода всех атрибутов
будет

O( M * log( N ) )

где M -- число атрибутов выводимой сущности.
Это ну никак не экспоненциальный рост. А линейный.
Ну и на практике

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

Чем это плохо ?
Кстати, время будет ровно такое же.

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

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

Posted via ActualForum NNTP Server 1.4

On 11.10.2010 13:41, OLEG_2005 wrote:

> То есть, если у меня есть контейнер с сущностями, которые могут иметь
> динамические параметры, список параметров, хранится в связанной с контейнером
> таблицы, то вполне примелемым выглядит решение: получить для данного контейнера
> список объектов, динамически сформировать запрос для вывода сущностей контейнера
> с объединениями (число которых равно числу параметров контейнера сущностей)?

Я проблем не вижу. Ты видешь ? Какие ?

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

Она не будет регулярной структуры. Это точно.

Posted via ActualForum NNTP Server 1.4

On 11.10.2010 16:26, OLEG_2005 wrote:
> В книге Pragmatic SQL Pattern рекомендуется делать так, но мне не нравится
> усложнение приложения в этом случае.

На самом -то деле приложению как раз должно быть достаточно всё равно, как
получать атрибуты. Разве что шняги типа Delphi & VisualBasic нельзя будет
в лоб применять.
Posted via ActualForum NNTP Server 1.4