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

On 12.10.2010 17:34, OLEG_2005 wrote:
> Кстати, интересно ваше мнение, использование изменение структуры таблицы с
> помощью ALTER TABLE может ли рассматриваться, как аналог EAV?

В смысле, как альтернатива EAV ? Бредятина это. Я уже писал, очень сильно
не на-ALTER-иш, быстро упрёшься в физический предел размера одной записи.
Posted via ActualForum NNTP Server 1.4

On 12.10.2010 18:18, miksoft wrote:

> 1) С нехваткой кэша открытых таблиц
> <http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_table_cache>
> в MySQL

> 2) с тормозами на уровне файловой системы из-за большого количества файлов в
> каталоге (если используется MyISAM или InnoDB с включенной опцией
> innodb_file_per_table

miksoft, ты людей -то не пугай особенностями этой не-до-СУБД.
Это всё сугубо дебилизм архитектуры MySQL-ля.

Дело в том, что просто т.н. горизонтальное партицирование
таблиц (если это не физическое парт., поддерживаемое самой СУБД)
-- это по моему мнению страшное нарушение правил проектирования
РБД. Это грозит всяческими проблемами в будущем жизни БД да
и вообще не удобно при необходимости выполнять запросы, обрабатывающие
ВСЕ данные какой-то сущности.
Posted via ActualForum NNTP Server 1.4

On 13.10.2010 10:49, OLEG_2005 wrote:

> Здесь видимо проблема не в физическом размере одной записи, так как количество
> атрибутов весьма умеренное.

Только в этом и проблема.

Posted via ActualForum NNTP Server 1.4