Flying Dutchman,

Насколько я знаю, в mysql работа не таких средств для работы с xml, как в MS SQL Server.

NemoxurПостройте таблицу в котором храните дерево групп, подгрупп
и таблицы с атрибутами
всё можно сделать через таблицы в 4-6 норм форме акаунты, таблица люди и тд, постройте индексы и всё будет летать

Честно говоря, ваша идея объединение групп/подгрупп в одну таблице и указание в этом случае какой входит ли подписчик в подгруппу не совсем понятна.

Может быть кто-нибудь видел open source решение, где реализуется подобная функциональность сегиментации данных, когда есть набор атрибутов как постоянных, так и заданных пользователем и сегмент формируется наборо условий проверки. Интересно было бы посмотреть, как реализуют подобную функциональность.
Судя по всему, скрипт, запущенный в сron будеть смотреть неотравленные кампании и выбирать подписчиков, которые удовлетворяют некоторому условию.

Так же можно предположить, что семнентация данных будет применяться не всегда и может быть не так часто. Также вполне можно предположить, что не все списки будут иметь заданные пользователем поля. Но возможность сегментации и создания опреленных пользователем полей быть должна.
Условия в сегментах двух типов:
Значение Поле (общее для всех списков или специфичное для данного списка) - Оператор сравнения - Значение

Группы Оператор (входит в одну из подгрупп, во все, ни в одну) Подгруппы.

Мне кажется понятие группы/подгруппы эквивалентно в общем типу данных Checkbox.

Нашел коммерческую систему Interspire, построенную на Open Source.
Глянул на их БД, они активно используют паттерн Serialized LOB.
Вот пример таблиц сегментов, условия проверки для подписчиков хранятся в виде текста.

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

Описание типов данных в сисетме также задается строкой, сериализованным массив PHP.
Причем, как я понял типы данных бывают как глобальные, так и локальные.

Скриншот с таблицами с типами данных:

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


"Становятся громоздкими" - какое-то расплывчатое утверждение. Одни проекты становятся громоздкими, другие нет. Я недавно учавствовал в проекте по разработке веб-магазинов, в котором мы использовали EAV для хранения атрибутов различных товаров. Конечно, с EAV несколько медленнее, чем без него из-за более сложной структуры БД, но в нашем случае скорость работы была удовлетворительной.

Использование XML для хранения атрибутов было бы проще, но в этом случае возникли бы проблемы с поиском. Например, запрос такого вида: "Найти всю обувь марки Ferragamo черного цвета размера 44" с использованием XML реализовать значительно сложнее, чем с использованием EAV.

В последнем случае (для нашей реализации EAV) это решается одним простым запросом с использованием реляционного деления. Причем запрос один и тот же для любых атрибутов (просто он реализуется для SQL Server, для других СУБД может быть и сложнее). Конечно, здесь я имею в виду запросы с проверкой значений атрибутов только на равенство. Запросы типа "Найти все мониторы с дигональю от 17 до 21 дюйма" будут реализовываться сложнее. Хотя и в этом случай реализация с EAV будет проще реализации с XML.

Хотя, вроде бы, в последней версии SQL Server (наш проект разрабатывался под SQL Server 2008) появились средства для индексирования XML-полей и быстрого поиска в них (но я в пока еще не разобрался, так что сказать ничего не могу).

А если нужно извлечть двадцать атрибутов при использовании EAV, то нужно сделать 20 объединений, не будет ли это непримлимо медленным решением. Похоже с ростом количества атрибутов быстродействие запроса будет падать очень быстро.