1

我们正在构建一个文档存储解决方案，对于每个文档，我们需要存储大量额外的元数据以符合当地法规，范围从标题或描述等基本数据到相关事件的日期或处置和分类规则。

我见过不同类型的解决方案，但没有一个能说服我：

  1. 添加新的元数据槽时表在列中增长（因此它们的列与与文档关联的元数据一样多）
  2. 具有大量备用通用列的表。与 1 非常相似，但表不会增长（权限较少）
  3. 文档 ID、元数据键和元数据值的表。
  4. 3. 中包含元数据定义和元数据键的表被元数据 ID 替换。我们过去使用过这个解决方案。这些表最后有数百万行。
  5. 文档表或关联表中的文本字段，用于存储 XML 或其他结构化信息以及键值对中的所有元数据。

我偏向于数字 5，提供并行全文索引（Lucene.Net？其他？）以通过相关元数据进行搜索（并非所有内容都必须是“可搜索的”）。

有什么建议吗？类似的经历？

4

3 回答 3

1

表 1：文档信息（PK 为文档 ID）

表 2：元数据定义（PK 是元数据定义 ID）

表 3：文档 ID、元数据定义 ID、元数据值

最大的缺点是您要么必须有一个类型（大概是 varchar），要么必须有 n 列（其中 n 是您愿意存储的数据类型的数量），并且使用元数据定义表中的一列来确定要从表 3 中的哪一列中提取值。

我对列出的 5 个解决方案的看法：

  1. 增长表是一件痛苦的事情，并且可能会导致问题（特别是如果您想要/需要一个不可为空的元数据值）。
  2. 我讨厌“备用通用列”（即使它们很受欢迎）。
  3. 关闭，但这比我的解决方案更限制了您的元数据灵活性。如果您的元数据键和值相当基本，它可能会起作用。
  4. 我不太确定你所说的这个是什么意思——它和我提议的一样，还是别的什么？
  5. 我不喜欢将结构化 XML 存储在 RDBMS 中 - 恕我直言，您会失去 RDBMS 的大部分功能。

这就是我的想法——我从来没有设计过这样的系统，但我已经处理过使用其中几种方案的商业系统。

于 2009-05-07T16:10:33.037 回答
1

为什么不使用CouchDB？它的设计正是为了解决这种类型的要求。

如果这不是一个选项，请考虑使用 Lua 或 JSon（根据您的 #5 选项）作为元数据描述符。

于 2009-05-08T13:44:16.880 回答
1

也许你可以看看JCR（Java Content Repository）。JCR 是内容存储库的标准，它捕获了内容管理的常见要求，例如版本控制、全文搜索和编辑。它还提供了内容存储的抽象级别，这意味着您可以使用一个 API 将内容放入任何类型的存储系统，如数据库、xml 文件等。当然，您可以通过向文档添加一些属性来将元数据添加到文档中带有 JCR API 的文档节点。您不必担心文档和元数据的存储方式。JCR 会处理它。Jackrabbit 是 JCR 的参考实现。试试。

于 2009-05-15T17:16:14.407 回答