实体元数据存储架构

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

1. 增长表是一种痛苦，可能会导致问题（特别是如果您需要/需要不可为空的元数据值）。
2. 我讨厌'备用通用列'充满激情（即使它们很受欢迎）。
3. 关闭，但这比我的解决方案更能限制您的元数据灵活性。如果您的元数据键和值非常基本，则可能有效。
4. 我不确定你的意思是什么 - 它和我提议的还是一样吗？
5. 我不喜欢将结构化XML存储在RDBMS中 - 通过执行此操作，您将失去RDBMS的大部分功能。

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

Answer 2

为什么不使用CouchDB？它的设计正是为了满足这种要求。

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

Answer 3

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