实体元数据存储体系结构

Question

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

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

1. 当添加新的元数据槽时，在列中增长的表(因此，它们的列数量与与文档关联的元数据相同)
2. 有大量多余的通用列的表。非常类似于1，但表没有增长(权限减少)
3. 文档ids、元数据键和元数据值的表。
4. 具有3中元数据定义和元数据键的表被元数据ids替换。我们过去使用过这个解决方案。表的末尾有数百万行。
5. 文档表或关联表中的文本字段，它将XML或其他结构化信息存储在键值对中的所有元数据中。

我倾向于5号，提供一个并行的全文索引(Lucene.Net？其他？)通过相关元数据进行搜索(并非所有内容都必须是“可搜索的”)。

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

Answer 1

表1:文件信息(PK是文档ID)

表2:元数据定义(PK是元数据定义ID)

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

这样做的最大缺点是要么必须有一个类型(大概是varchar)，要么必须有n个列(其中n是您愿意存储的数据类型的数量)，然后在元数据定义表中使用一个列来标识表3中的哪一列来从中提取值。

我对以下五种解决方案的看法：

1. 增长表是一种痛苦，可能会导致问题(特别是如果您希望/需要一个非空元数据值)。
2. 我讨厌有激情的“备用通用专栏”(尽管它们很受欢迎)。
3. 关闭，但这比我的解决方案更限制元数据的灵活性。如果您的元数据键和值是相当基本的，它可能会工作。
4. 我不太清楚你说的这句话是什么意思--是和我的求婚一样，还是别的什么？
5. 我不喜欢在RDBMS中存储结构化XML --通过这样做，您将失去RDBMS的大部分功能。

这就是我的想法--我从来没有设计过这样的系统，但我处理过一些使用过这些方案的商业系统。

Answer 2

为什么不使用CouchDB呢？它正是为了满足这类需求而设计的。

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

Answer 3

也许您可以看看JCR()。JCR是内容存储库的标准，它捕获了内容管理的共同需求，如版本控制、全文搜索和编辑。此外，它还提供了一个关于内容存储的抽象级别，这意味着您可以使用一个API将内容放入任何类型的存储系统，如数据库、xml文件等。当然，您可以通过使用JCR向文档节点添加一些属性来向文档中添加元数据。您不必担心文档和元数据将如何存储。JCR会处理的。JCR的参考实现是一种新型的JCR。试一试。