БредятинаOLEG_2005Здравствуйте.
Скажите, пожалуйста, стоит ли по вашему опыту использовать EAV, если допустим количество атрибутов (атрибуты могут быть разных типов) ограничено допустим нескольким десятком. Одним из преимуществ EAV является возможность добавления неограниченного числа параметров.
Помогает ли ограничение числа параметров обойти использование EAV?
Если использовать EAV и допустим есть несколько десятков параметров и необходимо вывести все параметры сущности, то нужно либо делать либо сложные запросы с несколькими десятками объединения (кажется, что с ростом числа атрибутов быстродействие будет падать экспоненциально) , либо получать значения атрибутов не в столбцах, а в строках и обрабатывать полученный массив данных в приложении). Можете ли дать рекомандации по поводу того, при каком числе параметров быстродействие запроса например на получение атрибутов становится недопустимо низким.
Спасибо.
Судя по всему Вы используете какую-то странную СУБД, в которой нельзя добавлять неограниченное число характеристик объекта (или, другими словами, неограниченное число колонок в таблицу)? И поэтому Вам приходится задумываться о EAV?


Честно говоря ваша непонятна. Что вы имеете в виду?

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

OLEG_2005БредятинаСудя по всему Вы используете какую-то странную СУБД, в которой нельзя добавлять неограниченное число характеристик объекта (или, другими словами, неограниченное число колонок в таблицу)? И поэтому Вам приходится задумываться о EAV?

Честно говоря ваша непонятна. Что вы имеете в виду?Непонятно, зачем тут EAV. У вас будут каждый день новые атрибуты появляться?


Да, пользователи системы могут создавать для каждого из списка пользователей динамические атрибуты, которые должны содержать подписчики данного списка.
Например для всех подписчиков есть общие атрибуты для всех, например, email. Каждый пользователь системы, который управляет подписчиками должен создавать до нескольких десятков динамических атрибутов. Скриншот аналогичной системы, email обязательное общее поле, остальные могут добавляться и удаляться теми, кто управляет своими списками подписчиков.

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

OLEG_2005БредятинаСудя по всему Вы используете какую-то странную СУБД, в которой нельзя добавлять неограниченное число характеристик объекта (или, другими словами, неограниченное число колонок в таблицу)? И поэтому Вам приходится задумываться о EAV?

Честно говоря ваша непонятна. Что вы имеете в виду?Непонятно, зачем тут EAV. У вас будут каждый день новые атрибуты появляться?

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

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


Извините не совсем понятна ваша мысль. Если я получаю из БД массив вида
subscriber_id field value
1 field1 value1
1 field2 value2
2 field1 value1
2 field2 value

для того чтобы просто вывести в Виде данные надо преобразовать в таблицу. Что вы имеете в виду говоря "передавать атрибуты как "объект Вида массив, который представляет собой таблицу" "?

alexeyvgOLEG_2005для того чтобы просто вывести в Виде данные надо преобразовать в таблицу. Что вы имеете в виду говоря "передавать атрибуты как "объект Вида массив, который представляет собой таблицу" "?Я имею в виду именно этот массив:
subscriber_id field value
1 field1 value1
1 field2 value2
2 field1 value1
2 field2 value
Именно его и можно передавать.

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

Да, динамический SQL с десятками джойнов выглядит не очень здорово.

Дело в том, что система предполагается использоваться для разных клиентов, которые должны отправлять рассылки своим подписчиками и управлять списками подписчиков. Клиенты должны иметь возможность создать списко динамических параметров для каждого списка подписчиков и эти атрибуты должны храниться для подписчиков этого списка. Полагаю нужды клиентов разные, одни, допустим могут захотеть храниться для своих подписчиков только email (обязательное), имя, фамилию,
другие допустим дату также дату рождения клиента, его адрес и так далее. Данные разных клиентов хранятся в одной базе данных.

Кстати, интересно ваше мнение, использование изменение структуры таблицы с помощью ALTER TABLE может ли рассматриваться, как аналог EAV?

miksoftOLEG_2005Кстати, интересно ваше мнение, использование изменение структуры таблицы с помощью ALTER TABLE может ли рассматриваться, как аналог EAV?Функционально - может быть. С точки зрения эксплуатации системы - нет. ALTER TABLE может оказаться слишком дорогой операцией, да еще, скорее всего, требующей монопольного доступа к таблице. В MySQL, например, ALTER TABLE часто выполняется как создание новой таблицы с нужными полями и переписывание всех данных из старой таблицы в новую. В местном MySQL-подфоруме был топик, в котором ALTER TABLE выполнялся несколько часов.

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

miksoftOLEG_2005Для большой таблицы данной способ неприменим.Все-таки зависит от СУБД и от деталей. Например, в Оракле добавление поля в таблицу с дефолтным NULL-значением в конец списка полей - достаточно быстрая опреация, т.к. затрагивает только словарь, но не затрагивает саму таблицу.
Но, сами понимаете, если удастся ужиться в рамках какой-то конкретной СУБД, то на другие СУБД переезд, скорее всего, будет невозможен.
OLEG_2005А если для каждого списка пользователей использовать отдельную таблицу и количество подписчиков в не было бы умеренное (ну скажем максим несколько десятков, максимум тысяч, а во многих несколько тысяч)?Во-первых, можно получить деградацию общей производительности из-за роста количества таблиц (если их количество будет измеряться многими тысячами) и из-за накладных расходов на ALTER TABLE (если используемая СУБД будет производить перестройку таблицы).
Во-вторых, это может сделать невозможным/затруднительным одновременную работу нескольких человек в одном аккаунте.

Еще один момент - ALTER TABLE невозможно выполнить в рамках транзакции. Т.е. он закоммитит транзакцию, если она была открыта на тот момент, и его самого невозможно откатить.

Используется MYSQL.

miksoftOLEG_2005Для большой таблицы данной способ неприменим.Все-таки зависит от СУБД и от деталей. Например, в Оракле добавление поля в таблицу с дефолтным NULL-значением в конец списка полей - достаточно быстрая опреация, т.к. затрагивает только словарь, но не затрагивает саму таблицу.
Но, сами понимаете, если удастся ужиться в рамках какой-то конкретной СУБД, то на другие СУБД переезд, скорее всего, будет невозможен.
OLEG_2005А если для каждого списка пользователей использовать отдельную таблицу и количество подписчиков в не было бы умеренное (ну скажем максим несколько десятков, максимум тысяч, а во многих несколько тысяч)?Во-первых, можно получить деградацию общей производительности из-за роста количества таблиц (если их количество будет измеряться многими тысячами) и из-за накладных расходов на ALTER TABLE (если используемая СУБД будет производить перестройку таблицы).
Во-вторых, это может сделать невозможным/затруднительным одновременную работу нескольких человек в одном аккаунте.

Еще один момент - ALTER TABLE невозможно выполнить в рамках транзакции. Т.е. он закоммитит транзакцию, если она была открыта на тот момент, и его самого невозможно откатить.

А чем может быть вызвана деградация производительности из-за большого количества таблиц в системе?

ScareCrowавторА чем может быть вызвана деградация производительности из-за большого количества таблиц в системе?
про такое еще слышать не доводилось. очень будет интересно посмотреть на человека который будет въезжать в базу с парой тысяч таких таблиц.

Возможно в данном случает такой подход и не даст каких-то выгод. Но судя по всему такой подход иногда используется используется. Можете посмотреть здесь:
http://msdn.microsoft.com/en-us/library/aa479086.aspx

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

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


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

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

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


На данный момент я не вижу альтернативы EAV, несмотря на все недостатки данного подхода. Буду смотреть к чему это приведет и насколько усложнит систему.

miksoftMasterZivmiksoft, ты людей -то не пугай особенностями этой не-до-СУБД.
Это всё сугубо дебилизм архитектуры MySQL-ля.OLEG_2005Буду смотреть к чему это приведет и насколько усложнит систему.Не могу не согласиться с MasterZiv, MySQL - не лучшая СУБД для такой задачи.
Мне доводилось оптимизировать запрос для EAV-таблицы в MySQL - два дня убил. И запрос получился <censored> по своей структуре, читабельности и поддерживаемости.

А можно узнать, с каким проблемами вы сталкивались при использовании MYSQL? Какие запросы было трудно оптимизировать в MYSQL?
Вы использовали множество JOIN для вывода всех атрибутов или получали атрибуты в строках и выполняли обрабтку в программе, если вам нужно было выводить сущность со значениями атрибутов?