Дизайн базы данных: в EAV или не в EAV?

Question

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

1) Есть ли у меня основная таблица и связана ли она со вторичной таблицей пар имя-значение?Все атрибуты помещаются во вторичную таблицу EAV.

• ИЛИ -

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

• ИЛИ -

3) Какой-то другой подход у меня нетдумал о?

Answer 1

Вы можете использовать решение два по соображениям эффективности, в частности, если вам нужно часто выбирать эти количества. Эти значения могут быть «кешем» таблицы EAV, если хотите. Вы вводите дублирование, но ускоряете поиск.

EAV является хорошим решением для этой проблемы, если вам не нужно выполнять объединения на уровне БД. Альтернатива - отойти от реляционной модели и перейти к модели на основе RDF.

Answer 2

Я проделал большую работу с шаблоном EAV, и он достаточно хорошо послужил цели.Я считаю, что пустые столбцы или динамические столбцы (например, col1, col2 и т. Д.) Гораздо сложнее иметь дело с управлением после факта, но их проще запрашивать, поскольку вам не нужно столько объединений.

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

Answer 3

Как правило, много пустых ячеек дешевы и не требуют нормализации.Единственный недостаток # 2 - это если у вас очень большое количество строк (миллионы - там, где могут возникнуть проблемы с производительностью), очень большое количество столбцов (более 20 - там, где просто смотреть на данные),или существует ряд уникальных ограничений на таблицу EAV.

С учетом вышесказанного, сейчас 2011 год, и в наши дни имеет смысл использовать среду программирования со слоем абстракции базы данных, чтобы вы не проектировалиотношения с базой данных напрямую.Что-то вроде Object Relational Mapper Django позволяет вам сосредоточиться на самих моделях и позволить наилучшим методам заботиться о себе (95% времени).Этот учебник поможет вам начать работу.Django относится только к моделированию баз данных веб-разработки.Для не-веб-сред лучше будут другие фреймворки.