Как сохранить метаданные по столбцам

Интересный сценарий. Вы можете обойти гетто EAV, думая о своих сущностях как о первоклассных объектах; назовем их Фактами. И помогает то, что в этом случае вы довольно ортогональны, поскольку в каждом фильме есть одни и те же четыре факта. Ваша таблица EAV может быть вашей нетронутой / правильной таблицей, а затем у вас может быть внешний процесс, который добывает эту таблицу и реплицирует данные в правильно нормализованную форму (то есть вашу первую таблицу). Таким образом, у вас есть нужные вам данные с их метаданными, и у вас есть простой способ запрашивать информацию о фильмах с точностью до того, как часто выполняется ваш процесс добычи.

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

Вот еще одна идея ... не стесняйтесь пробивать в ней дыры :)

Table: Movie
Columns: MovieId|Movie|Director|LeadMale|LeadFemale|Villain

Table: MovieSource
Columns: MovieSourceId|MovieId|MovieRoleId|Source|Journalist

Table: MovieRole
Columns: MovieRoleId|MovieRole
Values: 1|Director, 2|LeadMale, 3|LeadFemale, 4|Villain

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

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

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

-Dan

Поскольку у вас есть только два поля для исходных данных (Источник и Журналист), я бы порекомендовал таблицу метаданных, подобную этой:

Movie    DirectorSource  DirectorJournalist  LeadingMaleSource  LeadingMaleJournalist ...
---------------------------------------------------------------------------------------
The Tick   Yahoo           Cameron           ...                ...

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

Я бы посоветовал EAV только если ...

• У вас более 3 полей исходной мета -data
• Вам понадобится , чтобы иметь возможность легко добавлять или изменять поля фильма. (изменение типа «Злодей» на «Основной злодей» выполняется несколько раз в день)

Мой ответ может показаться слишком философским для SO. Потерпите меня.

Я думаю, что столбец «Источник» - это не предметные данные, а скорее метаданные. На самом деле это данные о том, как мы узнаем некоторые другие данные. Это делает его данными о данных, и это метаданные.

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

Я знаю, почему никогда не делал этого, но не могу объяснить это кратко.

Поскольку никто больше не занимается этим, я собираюсь ответить на свой вопрос. Я почти уверен, что таблица в стиле EAV - действительно единственный выход. Для хранения метаданных в каждом столбце (в данном случае относительно источника и журналиста) вы действительно рассматриваете каждый столбец как отдельную сущность, что позволяет EAV.

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

Хм .... Я не использовал это, поэтому я говорю не исходя из опыта (т.е. не вините меня, если это не работает), но на первый взгляд это кажется, что вы можете хранить «общие» данные, которые, как вы знаете, всегда будут там, как в обычной таблице, и «метаданные», которые могут изменяться в формате XML. Тогда вопрос в том, как правильно запросить его, и я думаю, вы могли бы сделать это, как описано ЗДЕСЬ .

Другой подход, который следует рассмотреть, - это наследование таблицы классов. У Билла Карвина есть отличный обзор вариантов EAV в этом SO-ответе и много хорошего контекста.

Я бы принял решение, основываясь на том, что мне нужно кодировать.

Если src / journo - это просто дополнительная информация, я бы выбрал дополнительные столбцы. Но если я знаю, что собираюсь создавать сложные запросы src / journo, я бы выбрал EAV, так как будет легче искать ссылки на журналиста по мета-таблице, чем искать в LeadingFemaleJournalist ] и VillainJournalist и т. д.

Лично я был бы склонен выгружать метаданные src / journo в другую таблицу в стиле EAV, но использовать FK для определения таблицы определения атрибутов. Наличие текстового поля атрибута произвольной формы - верный путь к катастрофе - всегда управляйте своими атрибутами с помощью ограничения. При необходимости могут быть реализованы триггеры для улучшения ссылочной целостности.

Для меня это сводится к точке зрения. Считаете ли вы, что источники и журналисты сами по себе вызывают озабоченность в отношениях, или они просто дополнительные данные, дополняющие Фильм ? Следующим уровнем уточнения будет создание различных таблиц для MovieDataSource и MovieDataJournalist , которые могут позволить вам сопоставить FK с таблицами, определяющими действительные источники и Журналисты (и дополнительная информация об этих Источниках / Журналистах может быть конкретизирована). Здесь вы должны установить связь «многие ко многим» между объектом Movie и объектом Source (а также Journalist ).