Дизайн базы данных: варианты EAV?

Question

Это просто вопрос концепции базы данных: каковы плюсы и минусы следующей модели для EAV?

Модель 1:

TABLE: attribute_value
======================================
| id | fk_id | attribute | value     |
======================================
| 1  | 10    | FName     | John      |
| 2  | 10    | Lname     | Doe       |
| 3  | 55    | FName     | Bob       |
| 4  | 55    | Lname     | Smith     |
--------------------------------------

Модель 2:

TABLE: attribute
==================
| id | attribute |
==================
| 1  | FName     |
| 2  | Lname     |
------------------

TABLE: value
=====================================
| id | attribute_id | fk_id | value |
=====================================
| 1  | 1            | 10    | John  |
| 2  | 2            | 10    | Doe   |
| 3  | 1            | 55    | Bob   |
| 4  | 2            | 55    | Smith |
-------------------------------------

Одно преимущество, которое я вижу с моделью 2, заключается в том, что attribute не содержит дубликатов.

Answer 1

Несмотря на минимализм, как показано, в таблице атрибутов Model2 вводится концепция метаданных в миксе со всеми вытекающими из этого преимуществами.У Model2 есть и другие преимущества, например, повышение производительности , связанное с меньшим размером строки (таблицы Value), но я бы хотел сосредоточиться на концепции метаданных.

Даже как есть Таблица атрибутов Model2 составляет хранилище всех допустимых атрибутов (с моделью 1 для получения такого списка потребуется выполнить совокупный запрос сортов).Кроме того, и как есть , хранилища достаточно, чтобы ввести ограничения внешнего ключа , чтобы помочь поддерживать целостность набора данных (с моделью 1 потребуются внешние формы проверки значенийхранится в столбце атрибутов.

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

• информация, такая как удобное для отображения имя каждого атрибута
• некоторые флаги, указывающие тип поля (числовое или строковое сопоставление с датой и т. Д.), Для дифференцированной обработки / обработки
• конкретная таблица значений, в которой хранится базовый атрибут (модель показывает только одну таблицу, но оптимизация / масштабирование иногда вызывает разбиение таблиц)
• тот факт, что атрибут может храниться в виде своего собственного столбца в таблице «Значение» (снова форма оптимизации, по сути, получая лучшее из обоих миров:гибкость схемы модели EAV, но производительность традиционной реляционной модели для атрибутов, которые являются наиболее используемыми и / или наиболее общими для всех объектов.
• возможность переименовывать атрибуты, не нарушая основную таблицу,Изменения только на уровне метаданных.
• различная прикладная семантика.Например, индикаторы того, что определенный атрибут должен быть предложен как одно из базовых и расширенных полей поиска.

В двух словах, таблица атрибутов становится ресурсом, который позволяет приложению быть действительно управляемым данными(или, точнее, meta управляемый данными).Действительно, вам также может понравиться таблица сущностей, то есть та, в которой собраны метаданные, относящиеся к различным типам сущностей: какие это разные типы сущностей, какие атрибуты разрешены для какого типа сущности и т. Д.обратите внимание на комментарий от zerkms , ниже самого вопроса.Несмотря на все свои преимущества, модель EAV также имеет свои недостатки и проблемы, намекающие на сложность запросов и проблемы с производительностью.Эти проблемы, однако, не должны дисквалифицировать, априори, EAV: во многих случаях использование EAV является лучшим подходом.
Если предположить, что EAV - это выбор, чем Model2, или даже что-то более сложное, безусловно, превосходит модель 1.

Answer 2

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

Что касается внешних ключей, вы можете наложить ограничение внешнего ключа на «атрибут» в модели 1, если хотите.

Что касается плюсов и минусов, то между этими двумя реализациями EAV нет никакой разницы.Все баллы Билла Карвина относятся к обоим.

Answer 3

Для модели 2 вы можете навязать Foreign-Key для attribute_id и убедиться, что только определенные атрибуты могут входить в таблицу.

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