Здравствуйте.
Нужно реализовать хранение следующих объектов.
Список пользователей (контейнер для хранения пользователей). Список пользователей должен содержать список определенных пользователем полей для объектов пользователь, которые хранятся в данном списке.

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

Сегмент пользователей определенного списка пользователей, который представляет собой набор условий вида:
Объедниение условий: все, хотя бы одно из условий.
"Значение поля пользователя" Оператор "Значение".

Например, для списка пользователя List1 добавили дополнительное поле, Age.
Так, что сегмент для пользователей данного списка может быть
Age Больше 20.

Для реализвации данной схемы можно использовать наборы связанных таблиц. Но для выполнения проверок в этом случае придется часто в запросах объединять много таблиц.

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

Как вы думает имеет ли смысл хранить ненормализованные данные и использовать второй подход?
Кто-нибудь реализовывал такой вариант? Использую MYSQL и PHP.


Спасибо.

ShtockВопрос вспылывающий раза два в неделю. Ищите в данном форуме по слову EAV

Я уже смотрел http://www.sql.ru/forum/actualthread.aspx?tid=777825 и http://en.wikipedia.org/wiki/Entity-attribute-value_model.
Вопрос остался имеет ли смысл в данном случае испоользовать для хранения строки или множество связанных таблиц?

ShtockВопрос вспылывающий раза два в неделю. Ищите в данном форуме по слову EAV

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

Если хранить как строки, мне представляется усложняется редактировани данных.

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

SERG1257авторКак вы думаете имеет ли смысл хранить иногда сложные струтуры данных (объекты массивы) просто в виде строкиТогда уж как XML

Думаю можно и в XML. Просто интересно, храните ли вы неатомарные данные или этого не стоит делать ни при каких обстоятельствах.

Edd.DragonOLEG_2005Как вы думаете имеет ли смысл хранить иногда сложные струтуры данных (объекты массивы) просто в виде строки, а уже разбирать их в программе?
Я понимаю, что с точки зрения проектирования БД - это ересь, это нарушение первой нромальной формы, но тем не менее, кто-нибудь хранил когда-нибудь неатомарные данные в виде строки.
Я храню, но мне при этом не нужна ни фильтрация, ни сортировка по этим полям. Т.е. в бизнес-логике они никогда не используются разрозненно. Лишь вводятся в отдельных полях и выводятся в отдельные столбцы.

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

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

LSVOLEG_2005Просто интересно, храните ли вы неатомарные данные или этого не стоит делать ни при каких обстоятельствах.Ну как минимум нарушение 1-й норм. формы.
Не есть хорошо. Чтоб использовать, нужно иметь очень серьезные аргументы для этого.

Меня тоже очень смущает нарушение первой нормальной формы.
Возможная аргументация, которая мне видится сейчас, избежать запросов с объединением 6-7 таблиц, заменяя более простыми запросами, извлечения данных из строковых полей, распаковка в массив и обработка. Имеет ли такой способ право на существование? Насколько данный аргумент кажется убедительным?

egorychOLEG_2005Возможная аргументация, которая мне видится сейчас, избежать запросов с объединением 6-7 таблиц, заменяя более простыми запросами, извлечения данных из строковых полей, распаковка в массив и обработка. и вы, конечно, уверены, что парсинг строки, распаковка в массив, и обработка ( где, кстати, это будет происходить? ), будет быстрее, чем запрос с объединением каких-то 6-7 таблиц?

Нет я не уверен, что это быстрее и лучше, поэтому я и задаю это вопрос.
Как в этом случаем могла проиходить обработка: PHP скрипт мог получить строковое поле, проебразовать в массив (дерево XML или что-то в этом роде), пройти по массиву и проверить выполнения каждого условия.

egorych,

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

egorychOLEG_2005egorych,

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

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

egorychOLEG_2005То есть вы считаете, что в всегда хранить сложные струтуры в связанных таблицах, а хранение неатомарных данных в виде строки всегда является неправильным подходом?да. И это не я так считаю, это теория построения реляционных баз данных так считает. Если задача в конечном итоге и потребует денормализации, то в любом случае, не такой убогой.

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

egorychOLEG_2005То есть вы считаете, что в всегда хранить сложные струтуры в связанных таблицах, а хранение неатомарных данных в виде строки всегда является неправильным подходом?да. И это не я так считаю, это теория построения реляционных баз данных так считает. Если задача в конечном итоге и потребует денормализации, то в любом случае, не такой убогой.

С точки зрения проектирования БД согласен, что это ересь.
Но ведь вы не будете отрицать, что иногда в строке хранять неатомарные данные, например, в XML формате? Наверное иногда имеет смысл применять денормализацию.
Но тем не менее, вероятно, стоит сначала использовать нормализованные данные. А потому в случае необходимости прибегать к нормализации в случае необходимости.
Просто меня смутило, что для выполнения простых условий проверки, которые должны выполняться часто, необходимо использовать запрос с объединением большого числа таблиц.

Я думаю то, что я имел в виду насчёт хранения слабоструктурированных данных в одном поле называется serializedLOB.
http://www.martinfowler.com/eaaCatalog/serializedLOB.html

Нашел книгу Pragmatic.SQL.Antipatterns.
В ней сильно ругаю EAV, когда количество атрибутов заранее неизвестно, как альтернатива EAV предлагается:
Semistructured Data
If you have many subtypes or if you must support new attributes frequently,
you can add a BLOB column to store data in a format such
as XML or JSON, which encodes both the attribute names and their
values. Martin Fowler calls this pattern the Serialized LOB.
Download EAV/soln/create-blob-tables.sql
CREATE TABLE Issues (
issue_id SERIAL PRIMARY KEY,
reported_by BIGINT UNSIGNED NOT NULL,
product_id BIGINT UNSIGNED,
priority VARCHAR(20),
version_resolved VARCHAR(20),
status VARCHAR(20),
issue_type VARCHAR(10), -- BUG or FEATURE
attributes TEXT NOT NULL, -- all dynamic attributes for the row
FOREIGN KEY (reported_by) REFERENCES Accounts(account_id),
FOREIGN KEY (product_id) REFERENCES Products(product_id)
);
The advantage of this design is that it’s completely extensible. You can
store new attributes in the blob at any time. Every row stores a potentially
distinct set of attributes, so you have as many subtypes as you
have rows.
The disadvantage is that SQL has little support for accessing specific
attributes in such a structure. You can’t easily select individual attributes
within the blob for row-based restriction, aggregate calculation,
sorting, or other operations. You must fetch the whole blob of attributes
as a single value and write application code to decode and interpret the
attributes.
This design is best when you can’t limit yourself to a finite set of subtypes
and when you need complete flexibility to define new attributes
at any time.

В книге есть фраза, что системы с использование 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> Для списка подписчиков может быть создана группа и подгруппа.

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

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

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

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

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

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

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

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

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

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

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