Здравствуйте.

Здесь много раз обсуждался EAV, но по этому вопросу ничего стоящего найти не удалось.

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

1. Хранить в таблице значений несколько полей для значений атрибутов, что-то вроде:
entity_id attribute_id string_value integer_value date_value.
2. Создать несколько таблиц, каждая их которых хранит значения атрибутов определенного типа:
таблица для хранения строк VARCHAR(255), таблица для хранения чисел (UNSIGNED BIGINT), таблица для хранения дат (DATE type).
3. Хранить значения атрибутов как строки, но данный вариант заведомо не подходит, так как нужно производить фильтрацию по атрибутам, например, сравнивать числа, к тому же в этом случае, например, в поля, которые должны хранить числа, можно добавить любые символы.

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

MasterZivOn 16.12.2010 21:43, OLEG_2005 wrote:
> Скажите, пожалуйста, как, по вашему мнению, лучше хранить значения атрибутов
> разных типов в EAV?

Это:
> 2. Создать несколько таблиц, каждая их которых хранит значения атрибутов
> определенного типа:
> таблица для хранения строк VARCHAR(255), таблица для хранения чисел (UNSIGNED
> BIGINT), таблица для хранения дат (DATE type).\


3 -- это вообще не вариант.

А вот интересно именно ПОЧЕМУ 2 лучше, чем 1. На самом деле не так в них
много разницы. Но вот мне не нравится, что NULL-ы в записях с другим
типом данных будут портить статистику распределения значений по данному
атрибуту.


Что вы имеете виду? Вариант с разными таблицами рассмотрен как попытка уйти от NULL в одной таблице с несколькими столбцами для хранения значений разных типов.

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

Извиняюсь за неточность формулировки. Что касается третьего варианта, то я имел в виду следующее:

3. Использовать EAV и хранить значения атрибутов как строки (VARCHAR), но данный вариант заведомо не подходит, так как нужно производить фильтрацию по атрибутам, например, сравнивать числа, к тому же в этом случае, например, в поля, которые должны хранить числа, можно добавить любые символы, но данный вариант заведомо не подходит, так как нужно производить фильтрацию по атрибутам, например, сравнивать числа, к тому же в этом случае, например, в поля, которые должны хранить числа, можно добавить любые символы.

То есть этот вариант подразумевает:
entity_id attribute_id value (VARCHAR)

MasterZivOn 17.12.2010 10:07, OLEG_2005 wrote:

> 3. Использовать EAV и хранить значения атрибутов как строки (VARCHAR), но данный
> вариант заведомо не подходит, так как нужно производить фильтрацию по атрибутам,
> например, сравнивать числа, к тому же в этом случае, например, в поля, которые
> должны хранить числа, можно добавить любые символы, но данный вариант заведомо
> не подходит, так как нужно производить фильтрацию по атрибутам, например,
> сравнивать числа, к тому же в этом случае, например, в поля, которые должны
> хранить числа, можно добавить любые символы.
>
> То есть этот вариант подразумевает:
> entity_id attribute_id value (VARCHAR)

Ещё раз, это вообще не вариант. Это -- нарушение доменной целостности данных,
грубейшая ошибка проектирования БД. Потом последствия её будут очень горькими.


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

MasterZivOn 17.12.2010 10:03, OLEG_2005 wrote:

> В варианте с несколькими таблицами смущает необходимость собирать атрибуты из
> нескольких таблиц, а не из одной таблицы.

А какая в .опу разница ?


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

MasterZivOn 17.12.2010 10:03, OLEG_2005 wrote:

> В варианте с несколькими таблицами смущает необходимость собирать атрибуты из
> нескольких таблиц, а не из одной таблицы.

А какая в .опу разница ?


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

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

Именно этот вариант. Проверку корректности производить на клиенте. Фильтрация идет, нет проблем.

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

_модOLEG_2005С этим вариантом связаны проблемы с целостностью данных и кроме того выполнять эффективно фильтрацию становиться проблематичным, все данные будут сравниваться как строки, а это не то, что нужно.
целостность и EAV несовместимы. сравнения нужно делать после преобразования. 90% данных в типовых системах обработки данных - строки.

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

_модOLEG_2005С этим вариантом связаны проблемы с целостностью данных и кроме того выполнять эффективно фильтрацию становиться проблематичным, все данные будут сравниваться как строки, а это не то, что нужно.
целостность и EAV несовместимы. сравнения нужно делать после преобразования. 90% данных в типовых системах обработки данных - строки.

Понятно, что, если есть возможность не использовать EAV, лучше этого не делать.
В данном случае без

В данном случае без EAV не обойтись.

guest_20040621> В данном случае без EAV не обойтись.

Исходную задачу сформулируйте.

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

_модOLEG_2005При преобразовании данных, например, строк в числа, индексы использоваться уже не будут.
Я храню все в строках. Есть индекс по значению. При поиске данные преобраз. в строки. Даты формата dd.mm.yyyy. Числа целые или с точкой.

Не понятно, как ты ищешь в BLOB значения и поддерживаешь целостность данных.
Ненормализованные данные - это не очень здорово.

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

;) А, вечный двигатель. Понятно.

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

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

guest_20040621> проверка типов на уровне БД вряд ли бывает лишней в любом случае

Конечно. Хотел подчеркнуть, что если мусор уже есть, то стоит ли бороться за его идеальную чистоту?

Не понятно, что вы называете мусором.

iscrafmOLEG_2005В данном случае без EAV не обойтись.
тяжело даже придумать такие случаи.

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

Допустим во всех списках всех атрибутов есть общий атрибут: 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

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

guest_20040621> Пример: списки объектов (пользователей)

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

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

guest_20040621> Пример: списки объектов (пользователей)

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

Так как набор атрибутов заранее не определено, то и паттерны вроде Single Table Inheritance, Concrete Table Inheritance и т. д. здесь применить не получится.

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

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

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

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

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

Бредятина,

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

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 хранить произвольный набор атрибутов, но чтобы осуществлять фильтрацию по атрибутам, нам нужно добавлять для них произвольный набор индексов, а это проблематично. К тому же такие системы имеют много других разных ограничений.