Допустим, вы собираете инсайдерскую информацию о предстоящих выпусках фильмов о супергероях, и ваша главная таблица фильмов выглядит примерно так:

Table 1

<code>Title              Director   Leading Male      Leading Female    Villain
--------------------------------------------------------------------------
Green Lantern      Kubrick    Robert Redford     Miley Cyrus     Hugh Grant  
The Tick          Mel Gibson  Kevin Sorbo        Linda Hunt    Anthony Hopkins
</code>

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

Однако вы хотите отследить источник каждого факта данных, а также имя журналиста, который обнаружил этот факт. Это, кажется, предполагает какую-тоEAV таблица как это:

Table 2

<code>Movie             Attribute            Value          Source          Journalist
----------------------------------------------------------------------------------
Green Lantern      Director           Kubrick         CHUD              Sarah
Green Lantern    Leading Male      Robert Redford     CHUD              James
Green Lantern   Leading Female      Miley Cyrus    Dark Horizons        James
Green Lantern      Villain           Hugh Grant       CHUD              Sarah
The Tick           Director          Mel Gibson       Yahoo            Cameron
...
</code>

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

Итак, мой вопрос в свете описанных мною сложностей, и, поскольку я знаю, что в целом таблиц EAV следует избегать, является ли EAV по-прежнему лучшим решением? Похоже, что это единственный разумный способ представления этих данных. Единственная альтернатива, которую я вижу, - это использовать таблицу 1 в сочетании с другой, котораяonly метаданные домов вот так:

Table 3

<code>Movie             Attribute            Source          Journalist
----------------------------------------------------------------------------------
Green Lantern      Director             CHUD              Sarah
Green Lantern    Leading Male           CHUD              James
Green Lantern   Leading Female      Dark Horizons         James
Green Lantern      Villain              CHUD              Sarah
The Tick           Director             Yahoo            Cameron
...
</code>

Но это очень опасно, потому что если кто-то изменит имя столбца в таблице 1, например & quot; Злодей & quot; «первичному злодею»; строка в таблице 3 будет по-прежнему просто "злодей" и, таким образом, связанные данные, к сожалению, будут отделены. Это может помочь, если атрибут "quot; attribute" quot; Столбец был связан с другой таблицей, которая служила перечислением столбцов таблицы 1. Конечно, администратор БД будет нести ответственность за ведение этой таблицы перечисления, чтобы она соответствовала фактическим столбцам таблицы 1. И это может быть даже возможно улучшить кроме того, вместо создания таблицы перечисления вручную, используйте системное представление в SQL Server, в котором хранятся имена столбцов в таблице 1. Хотя я не уверен, что вы можете иметь отношения, которые включают системные представления.

Что ты предлагаешь? EAV единственный путь?

А что, если это был только один столбец метаданных (просто «Источник» без «Журналист») - все равно необходимо идти по маршруту EAV? У вас могут быть столбцы & quot; Директор, & quot; & Quot; Director_Source, & Quot; "Ведущий мужчина" & quot; Leading Male_Source, & quot; и т.д., но это становится ужасно очень быстро. Есть ли какое-то лучшее решение, о котором я не думаю?

Если я не прояснил какой-либо пункт, прокомментируйте, и я добавлю больше по мере необходимости. О да, и данные фильма, которые я использовал, сфабрикованы :)

Изменить: для краткого изложения моего основного вопроса, я хотел бы иметь простоту и истинный дизайн РСУБД в таблице 1, которая действительно хорошо описывает запись фильма, при этом сохраняя метаданные о атрибутах безопасным и доступным способом. Это возможно? Или EAV единственный путь?

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

Update

Использование дизайна таблицы 2, за исключением переименования столбца «Фильм» на "Имя" и вызов всей таблицы "Кино" Вот операция поворота в SQL Server 2008 для возврата в таблицу 1:

<code>SELECT Name, [Director], [Leading Male], [Leading Female], [Villain]
FROM (Select Name, Attribute, Value FROM Movie) as src
PIVOT
(
Max(Value)
FOR Attribute IN ([Director], [Leading Male], [Leading Female], [Villain])
)  AS PivotTable
</code>