В книге есть фраза, что системы с использование EAV где-то через год становятся громоздкими.
Может ли кто-нибудь прокомментировать данное утверждение?
Если кого-нибудь заинтересует книга, пишите, могу скинуть по почте, она занимает около 1.5Mb, так что здесь выложить её не получится.

ScareCrowEAV имхо - наименьшее зло.
хранение в блобе или XML гораздо неудобнее.
на практике используют гибрид EAV - поля известные на этапе проектирования лежат в нормальных таблицах, поля пользовательские в EAV.

А в чем провляются основные недостатки?

У меня для списка есть от 1 до 3 постоянных полей, и до 40 полей определенных пользователем.
При чём вполне возможно, что полья определенные пользователем будут использоваться не так уж часто, но возможность их создания и проверки условий по всем полям быть должна.

ScareCrowEAV имхо - наименьшее зло.
хранение в блобе или XML гораздо неудобнее.
на практике используют гибрид EAV - поля известные на этапе проектирования лежат в нормальных таблицах, поля пользовательские в EAV.

Проблема гибридной системы указанной вами видится в сложности задания логической проверки, на основе атрибутов.
Допустим есть постоянные атрибуты Email, FirstName, LastName, которые храняться как обычные поля в таблице.
И есть специфические для определенного списка, которые хранятся как EAV, например, AGE.
Если для пользователя нужно хранить условие
Email содержит something@mydomain.com И AGE > 20, то возникает вопрос, как хранить такие данны в таблице, так как в одном случае атрибут - обычное поле в таблице, в другом случае - нет.

Как вы думаете в данном случае выбор может зависеть от используемой СУБД?

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

Нет, что-нибудь эдакого не хочется. Просто хочется решить задачу достаточно эффективно и не изобретать велосипед. Спасибо, за замечание. Я попытаюсь сформулировать задачу точнее.

Задача примерно такая:

Есть задача рассылать почту списку подписчиков, причём иметь возможность отправлять данные не обязательно всему списку, а некоторому сегменту, который удовлетворяет определенным условия.
В системе есть следующие объекты:
1. Списки подписчиков (lists). Список подписчиков – контейнер для хранения подписчиков.
2. Подписчики – пользователи, которым отправляется информация. Информация о подписчиках бывает как общая для всех подписчиков, например, электронный адрес, так и специфичный для списка, куда входит подписчик, набор атрибутов. Например, для некоторого списка могут быть список дополнительных полей о подписчиков, которые должны храниться для подписчиков данного списка. Отношения между списком подписчиков и подписчиком – один ко многим, если подписчик входит в несколько список сразу, то система их считает разными подписчиками.
3. Группы (groups) и подгруппы (dimensions). С каждый список пользователей может иметь произвольное число групп. Каждая группа содержит одну или более подгрупп. Таким образом, каждый подписчик данного списка может входить в одну или несколько подгрупп каждой группы.
4. Кампании (campaigns) – это сообщения, отправляемые подписчикам определенного списка подписчиков. Отношения между списком подписчиков и компаниями один ко многим.
5. Для кампании может быть задан не более одного сегмента, который представляет собой набор условий, объединенных либо по “И”, либо по “ИЛИ”. Условия бывают двух типов:
• Значение поля подписчика Оператор Значение (при чем поле может быть как общее для всех подписчиков списков, так и специфичное для данного списка).
• Имя группы Оператор (в одну из подгрупп, во все подгруппы, ни в одну из подгрупп) Список подгрупп.

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

guest_20040621> Есть задача рассылать почту списку подписчиков

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

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

Назначение таблиц, приведенных в схеме следующее:
1. Lists - списки подписчиков.
2. Campaigns - кампании.
3. Subscribers - подписчики, каждый подписчик входит только в один список и хранит как общие поля для всех подписчиков, например, email, так и специфичный для списка, куда он входит.
4. User_defined_fields - специфичные для списков поля, которые которые должных храниться для подписчиков данного списка.
5. Field_values - значения специфичных для данного списка полей подписчиков.
6. Field_choices - для некторых полей значений могут вводиться только из фиксированного набора, эти значение храняться в этой таблице.
7. Subscribers_types - информация о типе поля (не уверен, что эта таблица необходимо, но это пока не важно).
8. Groups - группа для списка, например, "Знание языков".
9. Dimensions - подгруппы данной группы, например, для группы "Знание языков" - "Английский", "Немецкий" и т.д.
10. Dimensions_subscriber - указывает подписчиков, которые входя в подгруппу данной группы.
11.Segment_conditions - условия проверка для сегмента кампании.
12. Segment_dimensions - подгруппы, проверка вхождения в которые проверяется для условия сегмента кампании.

guest_20040621> Подпичики могу группироваться в одну или нескольк подгрупп группы произвольно.

Нормальная реализация. Не хватает формального описания принципов группировки, если я правильно понял ваш ответ.

Могли бы вы, пожалуйста, пояснить, что вы имеете в виду?

guest_20040621,

Вы имеет под в виду подписчиков, когда говорите о юзерах?

guest_20040621Объекты, система, аккаунты - это просто слова. Есть юзеры, которые сгруппированы по некоторым правилам. Есть нечто, получаемое этими юзерами. Вопрос тривиален: как эти юзеры сгруппированы? Не надо схем и зависимостей, просто семантическое определение.

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

guest_20040621> Могли бы вы, пожалуйста, пояснить, что вы имеете в виду?

"Языки" можно интерпретировать по-разному. Это могут быть, например, языки, которые изучает пользователь или языки, которыми владеет пользователь. Также пользователь может иметь предпочтение, на каком языке он хотел бы получать рассылаемые материалы. Если использовать просто определение "языки", функциональная нагрузка такой группировки не очевидна.

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

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

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

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

Можете ли вы пояснить вашу мысль, может быть, на примере? Не совсем понятно, что вы имеет в виду.