RDBMS中元数据/标记的键值对：高效存储

Question

我知道键值对不是好的数据库设计，没有规范化等等，但在这种情况下我认为它们是最合适的解决方案。

我的理由和一些背景：大量项目被推入一组表格中，每个项目都可以使用用户可以选择的任意元数据进行标记。用户可以选择元数据，因为他们正在指定他们希望如何分类，报告和稍后查看项目。对于这个特定的业务问题，我们不能（作为系统设计者）说出这些维度是什么。项目之间没有一致的密钥集，在某些情况下，某个密钥的存在将被用作过滤条件。

另外一些背景信息，条目将被INSERT，但不是UPDATEd。最终它们将被删除（按顺序，按插入的顺序排列）。

问题，“高效存储”：由此我指的是查询（读取）性能。将使用以下类型的查询：

• 获取具有给定键，任意值
的项目
• 获取具有给定键和值的项目
• 获取包含所有键名的项目
• 获取包含所有键名和值的项目

基本上，这是给出这些选项的最佳选择？：

选项1

Items table:
item_id (integer, pk)
... item fields ...

ItemFacts table:
item_id (integer, fk)
key_name (nvarchar(64))
key_value (nvarchar(128))

选项2

Items table:
item_id (integer, pk)
... item fields ...

Facts table:
fact_id (integer, pk)
key_name (nvarchar(64))
key_value (nvarchar(128))

ItemFacts table:
item_id (integer, fk)
fact_id (integer, fk)

（可能存在第三种选择，其中将键名再次拉出到单独的表中以减少冗余，因为对于给定的键名称可能存在用于/可能的值的整个负载，也可能值得考虑）< / p>

粗略地说，将会有大量重复的键/值匹配。因此，应该存储效率提高。我意识到这是一个开放式的问题，但读取性能呢？如果我也介绍这个查询怎么样：？

• 获取给定键的值以“x”
开头的项目

如果我能提供更多说明，请告诉我。

Answer 1

你不需要借口来制作糟糕的设计。您的设计是您的选择。但要问一下搞砸我设计的最佳方法是什么，不是一个有很多答案而且没有好的答案的问题。真正的问题是我应该使用其他存储技术INSTEAD的RDBMS。

有些系统用于存储键值数据，如Cassandra。搜索NoSQL ...找到适合的技术。