Архитектура хранения метаданных сущностей

Question

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

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

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

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

Есть предложения? Подобные переживания?

Answer 1

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

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

Answer 2

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

Answer 3

Таблица 1: Информация о документе (PK - идентификатор документа)

Таблица 2: Определения метаданных (PK - это идентификатор определения метаданных)

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

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

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

1. Растущие таблицы - это боль, и они могут вызвать проблемы в будущем (особенно, если вы хотите / нуждаетесь в значении метаданных, не допускающих значения NULL).
2. Я ненавижу 'запасные общие столбцы' со страстью (хотя они популярны).
3. Близко, но это ограничивает гибкость ваших метаданных даже больше, чем мое решение. Если ваши ключи и значения метаданных довольно просты, это может сработать.
4. Я не совсем уверен, что вы подразумеваете под этим - это то же самое, что я предлагаю, или что-то еще?
5. Мне не нравится хранить структурированный XML в RDBMS - вы теряете большую часть мощности RDBMS, делая это IMHO.

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