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

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