Database design 为面向文档的数据库设计记录键-最佳实践

我们的团队已经开始开发Couchbase DB支持的应用程序；对于我们每个人来说，这是第一次使用无SQL数据库

我们已经开始定义实体，并采用Couchbase手册建议的使用“类型”前缀的做法：

Entity "A":
key: a#123

Entity "B":
key: b#123

但是我们意识到，我们在选择创建复合文档键的策略时感到困惑。我们经常使用计数器，它们需要自己的文档。我们的钥匙变得复杂：

Daily counter "x" for entity "A":
key: cntrx#a#123-20140117

我们已经考虑过不同的方法，但在这个问题上我们还是新手，希望能得到一些建议

---

分层键有什么好处吗？任何人都可以分享他们定义非平凡键的最佳实践吗？

在我们的项目中，我们使用分层键的方式如下所述： 键的第一部分类似于RDBMS中的表名：

用户

-表示“表”

在示例中，每个用户都有自己的id：

用户：1

-“代表一个用户”

我们使用了“：”，因为我认为它看起来比其他分隔符更好。您可以使用任何您喜欢的分隔符

如果要使用上一个示例中的顺序索引，如

id

，则需要从某个键获取它们，因此：

用户：计数器

-保存“最后一个用户id”的键（其作用类似于自动递增）

如果您需要为用户帐户存储某些“子部分”，您可以存储它：

---

用户：关于你的问题，我有几点建议

总体上
Nosql就像它听起来一样，需要一种与以前设计好的SQL数据库截然不同的思维方式。例如，nosql数据库基本上是一个大的哈希映射。因此，尽管将想法放在密钥中（例如，使密钥变小）可能会很好，但请记住，它们只是访问文档的一种手段。除非让它们看起来有某种特殊的优势，否则它们根本不需要有任何意义——通常首先需要进行主查找。举个例子，在导航到你的应用程序时，你的用户多久会知道他们需要直接请求“b#123”？我能想到的唯一有利的地方是用户名或用户知道的其他数据

复合键
虽然CB手册可能会建议使用复合键（对于简单的数据库结构也可能是这样），但一般来说，键的大小应该尽可能小。密钥最大限制为256字节。所有的密钥都必须存储在RAM中，因此密钥中的数据越多，其余数据可用的数据就越少。相反，我建议您在文档中创建一个类型字段，然后使用视图拉出特定类型的对象（或按类型索引对象）。这将最终为您提供更大的灵活性

计数器
您对计数器的解释相当模糊，因此我假设您将它们用作自动递增键。我建议在这里改变方法，以避开柜台。我对数据库中的所有密钥使用唯一标识符。当我使用复合键时，是因为键本身很重要（例如，在版本控制文档中，我使用文档id+文档保存日期的复合键，以确保其唯一性）。即使您有数百万（甚至数十亿）个对象，也可以使用12字节的GUID来保证文档ID的唯一性。这可以在需要保存新记录时防止应用程序中出现严重的瓶颈