miksoftOLEG_2005А можно узнать, с каким проблемами вы сталкивались при использовании MYSQL? Какие запросы было трудно оптимизировать в MYSQL?
Вы использовали множество JOIN для вывода всех атрибутов или получали атрибуты в строках и выполняли обрабтку в программе, если вам нужно было выводить сущность со значениями атрибутов?Тот запрос был наоборот, для поиска объекта по набору атрибутов.
Сначала пытался использовать варианты с множеством JOIN-ов и с GROUP BY ... HAVING COUNT(*)=..., но в итоге пришлось их совмещать.

А отображение атрибутов в той системе проблемой не было, так как требовалось отобразить атрибуты ровно одного объекта.

А сами атрибуты вам надо было редактировать?

MasterZiv
On 13.10.2010 10:49, OLEG_2005 wrote:

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

Только в этом и проблема.



А могли бы пояснить, что вы имеете в виду, говоря о проблеме с физиским размером одной записи?

А могли бы пояснить, что вы имеете в виду, говоря о проблеме с физическим размером одной записи?

MasterZiv
On 13.10.2010 13:12, OLEG_2005 wrote:

> А могли бы пояснить, что вы имеете в виду, говоря о проблеме с физиским размером
> одной записи?

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


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

MasterZiv
On 13.10.2010 13:12, OLEG_2005 wrote:

> А могли бы пояснить, что вы имеете в виду, говоря о проблеме с физиским размером
> одной записи?

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


А вот требование наличие возможности изменения набора атрибутов наверное не оставляет альтернативы использованию EAV.

miksoftOLEG_2005Я пока не нашел максимальный размер записи для MYSQLНеубедительно.
тынц1
тынц2
это первое, что подвернулось...

Большое спасибо за ссылки.

Как вы думаете может для подобных систем нецелесообразно использовать реляционные БД вообще, а использовать что-то вроде:
Amazon SimpleDB.

miksoftOLEG_2005Как вы думаете может для подобных систем нецелесообразно использовать реляционные БД вообще, а использовать что-то вроде:
Amazon SimpleDB.Зависит от масштабов и нагрузки. Сомневаюсь, что у вас случатся такие нагрузки, что РСУБД станет недостаточно. Даже MySQL-я хватит надолго, если правильно его готовить.

Прогнозировать нагрузку сейчас довольно тяжело, если ориентироваться на аналогичные серисы, то это десятки - сотни тысяч клиентов, каждые из которых хранят тысячи - десятки - иногда сотни тысяч подписчиков и которым надо регулярно отправлять рассылки (персонифицированные), которые делает клиент. Каждый клиент может содержать несколько списков подписчиков и отправлять кампанию как все подписчикам списка, так и некоторому сегоменту, который предавлятеся собой набор условий по атрибутам подписчиков.
Как я понял в системах подобных Amazon SimpleDB для повышения масштабирования в жертву приносится целостность данных. Может быть я не прав. Похоже такие системы позволяют легко решить задачу переменного числа атрибутов, но не усложняют ли они другие вещи?

miksoftOLEG_2005Прогнозировать нагрузку сейчас довольно тяжело, если ориентироваться на аналогичные серисы, то это десятки - сотни тысяч клиентов, каждые из которых хранят тысячи - десятки - иногда сотни тысяч подписчиков и которым надо регулярно отправлять рассылки (персонифицированные), которые делает клиент. Каждый клиент может содержать несколько списков подписчиков и отправлять кампанию как все подписчикам списка, так и некоторому сегоменту, который предавлятеся собой набор условий по атрибутам подписчиков.Ничего не посильного для РСУБД тут не вижу. Тем более, что вы наверняка сильно переоцениваете масштабы.
В любом случае - начинайте на любой СУБД, хоть на MySQL. Переписывать все с нуля все равно на определенном этапе придется, когда поймете каких ошибок понаделали и груз этих ошибок станет слишком тяжел.

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

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

Сложность - работа с подписчиками, которые могу иметь как стандартные атрибуты (храняться в столбцах таблицы подписчиков), так и динамические атрибуты EAV.
Логика манипулирования таким подписчиками в списке усложняется, даже например, такая тривиальная операция как вывод всех атрибутов списка со всеми атрибутами (как постоянными, так и динаическими), а таке список групп, куда входит подписчик (с каждым списком может быть связано произвольное число груп, куда могу входить подписчики списка, становится довольно непростой задачей.
Тоесть вывод что-то вроде
Подписчики списка 1:
email (постоянное поле) далее динамические firstname lastname Любимые бренды (название группы)
sfff@gmail.com Panasonic, SONY, Toshiba

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

Нашел ссылку на ещё один метод реаклизации набора атрибутов, определяемых пользователем. Её называют the Fixed Table. Предполагается, что число возможных атрибутов определяемых пользователем ограничено.
Её можно посмотреть здесь:
http://blog.springsource.com/arjen/archives/2008/01/24/storing-custom-fields-in-the-database/
Кто-нибудь пробовал реализовывать похожую модель? Она вообще реализуема на практике?

miksoftOLEG_2005Она вообще реализуема на практике?Вполне реализуема.
Только делает весьма затруднительным поиск объекта по произвольному набору атрибутов.

В чем вы видете проблему помска побъекта по произвольноому набору атрибутов?
В этом случае пришлось бы, видимо, добавлять огромное число индексов, для поиска по всем атрибутам.