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

Здесь много раз обсуждался 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 не обойтись.