Бредятина,

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

guest_20040621> Задать набор атрибутов на все случае жизни в данном случае не представляется возможным.

Это стандартная отговорка. В данном случае в зависимости от конечной задачи набор атрибутов будет разным, но конечным. С одной стороны он ограничен требованями о защите персональных данных (которые будут различаться от государства к государству), с другой - практической целесообразностью.

> то и паттерны вроде

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

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

БредятинаOLEG_2005Пример: списки объектов (пользователей), каждый список хранить - набор пользовательских атрибутов, которые должны храниться для каждого пользователя списка.
То есть все пользователи имеют постоянные атрибуты - общие для всех список, а есть атрибуты специфичные для списка.
Допустим во всех списках всех атрибутов есть общий атрибут: email_address.
Допустим в списке List1 есть пользовательский атрибуты: FirstName, LastName, Age.
Допустим в списке List2 есть пользовательский атрибуты: Date_Birth, Weight, Height.
В списке List3 вообще нет пользовательских атрибутов.
Для списка List1 мы должны хранить:
email_address FirstName LastName Age
test Vasya Ivanov 20

Для списка List2 мы должны хранить:
email_address Date_Birt Weight Height
test1 1983.03.09 80 185

Для списка List3:
email_address
test3

Списки атрибутов для каждого списка могут задаваться пользователем, они могут быть разными, так как назначение списков могут быть очень разными.
Предполагается, что типы атрибутов будут одного из типов пока: строковые, числовые и дата.
Для этого EAV, конечно, не нужна. Видимо, одна из Ваших задач, обязательно использовать некую "реляционную" СУБД, в которой пользователи не могут добавлять сколько угодно характеристик объекта, и как угодно их группировать. И именно поэтому Вам приходится смотреть в сторону EAV. EAV имела бы, по крайней мере, теоретическое обоснование, если пользователям нужно постоянно произвольно добавлять отношения (таблицы) (или "классы", хотя, хорошо известно, что "таблица" в реляционной системе - это не "класс" в объектной). То есть, объекты, а не характеристики объектов.

У вас есть предложения, как решить задачу с возможностью хранить произвольный набор атрибутов и фильтровать по ним без EAV?

БредятинаOLEG_2005Пример: списки объектов (пользователей), каждый список хранить - набор пользовательских атрибутов, которые должны храниться для каждого пользователя списка.
То есть все пользователи имеют постоянные атрибуты - общие для всех список, а есть атрибуты специфичные для списка.
Допустим во всех списках всех атрибутов есть общий атрибут: email_address.
Допустим в списке List1 есть пользовательский атрибуты: FirstName, LastName, Age.
Допустим в списке List2 есть пользовательский атрибуты: Date_Birth, Weight, Height.
В списке List3 вообще нет пользовательских атрибутов.
Для списка List1 мы должны хранить:
email_address FirstName LastName Age
test Vasya Ivanov 20

Для списка List2 мы должны хранить:
email_address Date_Birt Weight Height
test1 1983.03.09 80 185

Для списка List3:
email_address
test3

Списки атрибутов для каждого списка могут задаваться пользователем, они могут быть разными, так как назначение списков могут быть очень разными.
Предполагается, что типы атрибутов будут одного из типов пока: строковые, числовые и дата.
Для этого EAV, конечно, не нужна. Видимо, одна из Ваших задач, обязательно использовать некую "реляционную" СУБД, в которой пользователи не могут добавлять сколько угодно характеристик объекта, и как угодно их группировать. И именно поэтому Вам приходится смотреть в сторону EAV. EAV имела бы, по крайней мере, теоретическое обоснование, если пользователям нужно постоянно произвольно добавлять отношения (таблицы) (или "классы", хотя, хорошо известно, что "таблица" в реляционной системе - это не "класс" в объектной). То есть, объекты, а не характеристики объектов.
Значения произвольного набора атрибутов нужно не только хранить, но и фильтровать по ним.
Даже нереляционные БД не очень здесь могут помочь.
Допустим мы может в MongoDb хранить произвольный набор атрибутов, но чтобы осуществлять фильтрацию по атрибутам, нам нужно добавлять для них произвольный набор индексов, а это проблематично. К тому же такие системы имеют много других разных ограничений.

guest_20040621> используют списки для своей предметной области

Профессиональные навыки и профессиональное образование - вот источники специфичных отраслевых атрибутов. Но и они могут быть формализованы.

> Кто-то использует списка для того, чтобы делать рассылку пользователям о фильмах

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

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

Списки могут использоваться для самых разных отраслей.

guest_20040621> используют списки для своей предметной области

Профессиональные навыки и профессиональное образование - вот источники специфичных отраслевых атрибутов. Но и они могут быть формализованы.

> Кто-то использует списка для того, чтобы делать рассылку пользователям о фильмах

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

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

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

guest_20040621> Списки могут использоваться для самых разных отраслей.

Конечно. Но количество отраслей также конечно. Причем, относительно невелико.

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

guest_20040621> Списки могут использоваться для самых разных отраслей.

Конечно. Но количество отраслей также конечно. Причем, относительно невелико.

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

guest_20040621> Списки могут использоваться для самых разных отраслей.

Конечно. Но количество отраслей также конечно. Причем, относительно невелико.

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

guest_20040621> Непонятно, как иметь информацию о всевозможных отраслях и о наборе атрибутов для всех применений

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

> могут появляться новые применения для списков

Могут. Но и жизненый цикл ПО не "сдал - забыл".

> как это все предугадать?

Если цель вашего проекта - глобальная конкуренция сервисам от google, например, с задачей выйти на капитализацию лавки пару миллиардов через пару лет, то вопрос звучит странно. Видимо, должны быть люди, в задачу которых должен входить мониторинг рынков и прессы. Если же у вашего проекта другая цель, вопрос звучит еще более странно. Начните с малого, если появится необходимость решения задачи - вы знаете, как ее решать. Сахават, по-моему, на предыдущей странице совершенно четко рассказал о содержимом базы данных: если что-то вы можете описать стандартным образом - описывайте. Для того, что не можете (нет данных, например, или нет понимания востребованности данных), оставьте мусорный коллектор (структуру, о которой вы говорите). Возможно, часть данных из него с течением времени будет описана стандартным образом. Или выброшена.

В подобных системах функциональность с произвольным набором атрибутов реализована.

guest_20040621> Непонятно, как иметь информацию о всевозможных отраслях и о наборе атрибутов для всех применений

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

> могут появляться новые применения для списков

Могут. Но и жизненый цикл ПО не "сдал - забыл".

> как это все предугадать?

Если цель вашего проекта - глобальная конкуренция сервисам от google, например, с задачей выйти на капитализацию лавки пару миллиардов через пару лет, то вопрос звучит странно. Видимо, должны быть люди, в задачу которых должен входить мониторинг рынков и прессы. Если же у вашего проекта другая цель, вопрос звучит еще более странно. Начните с малого, если появится необходимость решения задачи - вы знаете, как ее решать. Сахават, по-моему, на предыдущей странице совершенно четко рассказал о содержимом базы данных: если что-то вы можете описать стандартным образом - описывайте. Для того, что не можете (нет данных, например, или нет понимания востребованности данных), оставьте мусорный коллектор (структуру, о которой вы говорите). Возможно, часть данных из него с течением времени будет описана стандартным образом. Или выброшена.

В качестве ориентира выбрана аналогичная система, в которой для каждого списка можно указать, набор атрибутов, который можно хранить, кроме стандартных.
На данный момент эта система обслуживает около 400000 пользователей, каждый из которых имеет свои списки.
По умолчанию для каждого нового списка набор пользовательских атрибутов два поля First Name и LastName (эти атрибуты могут быть удалены) и можно добавлять пользовательские атрибуты до 30 атрибутов, по-моему.

iscrafmOLEG_2005можно добавлять пользовательские атрибуты до 30 атрибутов, по-моему.
откуда взялось такое ограничение? Почему не 25 или 48? EAV же без разницы...

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

Использует ли система, о которой я говорил, EAV или нет я достоверно не знаю.
Насколько я знаю они используют MYSQL.

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

Это же очевидно. Что все эти, хоть атрибуты отношения, хоть характеристики объекта, используются в поисковых запросах. При чем здесь происхождение атрибута - разработчик его описал или пользователь? О чем Вы говорите? Опять же получается, что Вы находитесь в плену каких-то устоявшихся, и в корне неверных, представлений:)
OLEG_2005Допустим мы может в MongoDb хранить произвольный набор атрибутов, но чтобы осуществлять фильтрацию по атрибутам, нам нужно добавлять для них произвольный набор индексов, а это проблематично. К тому же такие системы имеют много других разных ограничений.
Ничего не понимаю. Зачем Вы приводите примеры "таких систем" со "многими другими разными ограничениями"?:) Ваша задача тривиальна, и не требует EAV. При чем здесь "такие системы"?

Какое решение вы имеете в виду?

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

Это же очевидно. Что все эти, хоть атрибуты отношения, хоть характеристики объекта, используются в поисковых запросах. При чем здесь происхождение атрибута - разработчик его описал или пользователь? О чем Вы говорите? Опять же получается, что Вы находитесь в плену каких-то устоявшихся, и в корне неверных, представлений:)
OLEG_2005Допустим мы может в MongoDb хранить произвольный набор атрибутов, но чтобы осуществлять фильтрацию по атрибутам, нам нужно добавлять для них произвольный набор индексов, а это проблематично. К тому же такие системы имеют много других разных ограничений.
Ничего не понимаю. Зачем Вы приводите примеры "таких систем" со "многими другими разными ограничениями"?:) Ваша задача тривиальна, и не требует EAV. При чем здесь "такие системы"?

Какое решение не связанное с EAV вы имеете в виду?

БредятинаOLEG_2005Какое решение вы имеете в виду?
Любое, основанное на классической объектной модели данных. Я за 28 лет не видел ни разу, чтобы в таких решениях были бы ограничения на добавление пользовательских "атрибутов" в "таблицы". Если у Вас нет такого решения, то реализовать его, например, в GT.M элементарно:)

Как без EAV вы представляете себе хранение произвольного набора атрибутов?

БредятинаOLEG_2005Какое решение вы имеете в виду?
Любое, основанное на классической объектной модели данных. Я за 28 лет не видел ни разу, чтобы в таких решениях были бы ограничения на добавление пользовательских "атрибутов" в "таблицы". Если у Вас нет такого решения, то реализовать его, например, в GT.M элементарно:)

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

БредятинаOLEG_2005Какое решение вы имеете в виду?
Любое, основанное на классической объектной модели данных. Я за 28 лет не видел ни разу, чтобы в таких решениях были бы ограничения на добавление пользовательских "атрибутов" в "таблицы". Если у Вас нет такого решения, то реализовать его, например, в GT.M элементарно:)

Что касается GT.M, я не знаком с этой этим продуктом и слабо представляю, как такое решение может помочь.

БредятинаOLEG_2005пропущено...


Как без EAV вы представляете себе хранение произвольного набора атрибутов?
Понадобилась еще одна характеритика объекта - добавили. Что здесь нужно представлять?:)

Вы имеете в виду, каждый раз изменять структуру таблицы?