Как хранить значения атрибутов разного типа как EAV? - PullRequest
Новая
       9

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

3 голосов
/ 17 декабря 2010

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

Я вижу 3 варианта сейчас.

  1. Хранить в одной таблице в разных полях что-то вроде: entity_id attribute_id string_value numberic_value date_value.
  2. Для хранения значений разных типов атрибутов в разных таблицах, например, string_attribute_values, numeric_attribute_values, date_attribute_values.
  3. Хранить значения всех типов как VARCHAR, но этот вариант кажется неподходящим, потому что трудно выполнить фильтрацию, например, по числовому значению (они будут сравниваться как строки), и, например, давайте введем букву в поля должны быть только цифры.

Полагаю, мне нужно сейчас: строка, число (целое число) и тип даты, но, возможно, другие типы появятся позже.

Спасибо.

1 Ответ

1 голос
/ 01 марта 2011

В сообществе RDBMS EAV является антипаттерном. Для «бесконечной гибкости», получаемой с помощью EAV, SQL, необходимый для восстановления данных в виде записей / объектов, значительно сложнее. Вы также получаете «преимущество» от невозможности использовать какие-либо доступные вам инструменты целостности данных (внешние ключи, проверочные ограничения и т. Д.). Со временем этот дизайн разрушается под собственным весом.

Если у вас есть вариант использования, в котором элементы данных являются частью отношений супертипа / подтипа, но они мало меняются, то моделируйте таблицы в соответствии с вашими потребностями:

1.) Наследование таблиц классов = таблицы конкретных подтипов с общим родителем. Это лучше всего, когда каждый из супертипа и подтипа имеет значительное количество уникальных атрибутов.

2.) Наследование конкретной таблицы = поместите общие столбцы супертипа в таблицу каждого подтипа. Это работает лучше, когда у супертипа не много собственных атрибутов, но у подтипов есть.

3.) Наследование одной таблицы = поместите столбцы для всех подтипов в 1 таблицу вместе со столбцами супертипа. Столбцы, которые не относятся к подтипу конкретной строки, имеют значение NULL. Это лучше всего подходит для случаев, когда каждый подтип не имеет много уникальных атрибутов или несколько подтипов совместно используют столбцы / атрибуты.

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

Если вам действительно нужно использовать EAV, вы используете столбцы XML в СУБД, если относительно небольшая часть ваших данных находится в вашем проекте EAV (по сравнению с общей базой данных). Если большая часть ваших данных будет храниться в EAV, тогда СУБД - не тот инструмент, который вам нужен. Посмотрите на базы данных document / NoSQL / Key-Value, такие как MongoDB, Cassandra и т. Д. СУБД, которые реализуют EAV, если не рано, в конечном итоге станут кошмаром кодирования.

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

...