guest_20040621> Что касается групп или подгрупп, мне кажется, что здесь семантика не очень важна

На мой взгляд, как раз принципиальна.

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

Однако, мне кажется, что в данном случае как раз семантическая классификация может быть решением вашей задачи.

Честно говоря, больше сказать в данный момент о семантике. Здесь семантика скорее определяется пользователем.
Для хранения этих слабоструктурированных данный подумывал о применении паттерна Serizalized LOB, то есть хранить данную в виде строки. Но в тоже время, я не уверен, что этот способ будет быстрее несмотря, на существенное уменьшение числа таблица, которые надо объединять для проверки в общем то не очень сложных условий.

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

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

Дело в том, что не существует групп единых для всех подписчиков, они специфичны для каждого списка, их создает владелец списка и это может быть абсолютно всё что угодно и использоваться в самых разных предметных областях.

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

guest_20040621> Здесь семантика скорее определяется пользователем.

;) На мой взгляд, было бы опрометчиво отдавать структурирование на откуп пользователям. Хотя... хозяин - барин, конечно.

> не уверен, что этот способ будет быстрее

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

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

guest_20040621,

Это Software as a service (SaaS) система, которая предоставляет возможность компаниям использовать рассылки.

У пользователя не может быть несколько адресов, только один email.

guest_20040621> У пользователя не может быть несколько адресов, только один email.

Это тоже требование заказчика? Легко представить себе как минимум адрес корпоративной почты и персональной. И персональные ящики тоже могут служить разным целям. Впрочем, это ваш заказчик. Ну... да, с очень ограниченным представлением о функционале того, что ему нужно, но это в данном случае плюс, поскольку уменьшает количество работы. ;)

Я думаю сделано это из-за того

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

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

Можно заполучить эту книгу ? Мой email в профайле.

Книгу вам отправил.

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


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

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

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

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

Я использую Mysql. А если у меня условия храняться в виде:
Значение поля Оператор сравнеия Значение, которые доспустим хранить в виде XML или JSON в БД.
То есть извлечь строковое поле и преобразовать в массив, пробежаться по нему для проверки условий?
Но в это случае труднее выполнять проверку целостности данных. И не факт, что обработка на PHP в этом случае была бы быстрее чем запрос с объединением таблиц.

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

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

Я подумаю, можно ли хранить группы и подгруппы в одной таблице.

Но в любом случае хранение двух типов условий в таблице segment_conditions кажется не очень красивым.