Архитектура хранения метаданных объектов

Question

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

Я видел различные типы решений, но никто не убедит меня:

1. Таблицы, которые растут в столбцах, когда добавляется новый слот метаданных (так что они имеют количество столбцов метаданных, связанных с документами)
2. Таблицы с большим количеством запасных общих столбцов. Очень похоже на 1. но таблицы не растут (меньше разрешений)
3. Таблица идентификаторов документов, ключей метаданных и значений метаданных.
4. Таблица с определениями метаданных и ключами метаданных в 3. заменена идентификаторами метаданных. Мы использовали это решение в прошлом. В конце таблицы есть миллионы строк.
5. Текстовое поле в таблице документов или связанной таблице, в которой хранится XML или другая структурированная информация со всеми метаданными в парах ключ-значение.

Я смещен в сторону номера 5, предоставляя параллельный полнотекстовый индекс (Lucene.Net? Other?) Для поиска по соответствующим метаданным (не все должно быть «доступно для поиска»).

Любое предложение? Подобный опыт?

Answer 1

Таблица 1: Информация о документе (ПК является ИД документа)

Таблица 2: Метаданные определения (ПК является определение метаданных ID)

Таблица 3: Идентификатор документа, метаданные Defintion ID, значение метаданных

Самым большим недостатком этого является то, что вы либо должны иметь один тип (предположительно), либо у вас должно быть n столбцов (где n - количество типов данных, которые вы хотите хранить) и используйте столбец в таблице определений метаданных, чтобы определить, какой столбец в таблице 3 вывести значение.

Мои мнения по 5 решений перечисленных:

1. Растущие столы боль, и может вызвать проблемы вниз линии (особенно, если вы хотите/нужно ненулевое значение метаданных).
2. I ненавижу «запасные общие столбцы» со страстью (хотя они и популярны).
3. Закрыть, но это ограничивает гибкость ваших метаданных даже больше, чем мое решение. Если ваши ключи и значения метаданных достаточно простые, это может сработать.
4. Я не совсем уверен, что вы подразумеваете под этим - это то же самое, что я предлагаю, или что-то еще?
5. Мне не нравится хранить структурированный XML в РСУБД - вы теряете большую часть мощности РСУБД, делая это ИМХО.

Это мои мысли. Я никогда не проектировал такую ​​систему, но я имел дело с коммерческими системами, которые использовали несколько из этих схем.

Answer 2

Почему бы не использовать CouchDB? Он разработан специально для решения этого требования.

Если это не вариант, рассмотрите возможность использования Lua или JSon (на ваш вариант # 5) в качестве дескриптора метаданных.

Answer 3

Возможно, вы можете взглянуть на JCR (репозиторий контента Java). JCR - это стандарт для репозитория контента, который учитывает общие требования к управлению контентом, такие как управление версиями, полнотекстовый поиск и редактирование. Кроме того, он предоставляет уровень абстракции в хранилище контента, а это означает, что вы можете использовать один API для размещения содержимого в любой системе хранения данных, такой как база данных, xml-файл и т. Д. Конечно, вы можете добавлять метаданные в свой документ, добавляя некоторые свойства к узел документа с JCR API. Вам не нужно беспокоиться о том, как будут храниться документ и метаданные. JCR позаботится об этом. Jackrabbit - эталонная реализация JCR. Попробуй.