我认为目前,NoSQL数据存储的整个概念和文档数据库的概念是如此新颖,与驱动关系存储的既定想法不同,目前很少(如果有的话)最佳实践 .
我们现在知道,将数据存储在CouchDB(或任何其他文档数据库)中的规则与关系数据的规则有很大不同 . 例如,实际上,3NF的标准化和瞄准并不是人们应该努力的事实 . 一个常见的例子是一个简单的博客 .
在关系存储中,每个“Posts”,“Comments”和“Authors”都有一个表 . 每个作者都有很多帖子,每个帖子都会有很多评论 . 这是一个运行良好的模型,可以很好地映射到任何关系数据库 . 但是,在docDB中存储相同的数据很可能会有很大不同 . 你可能有类似Post文档的集合,每个文档都有自己的作者和嵌入的评论集合 . 当然,这可能不是你能做到的唯一方法,而且它有点妥协(现在查询单个帖子很快 - 你只做一个操作并把所有东西都拿回来了),但你无法保持作者和帖子之间的关系(因为它都成为帖子文档的一部分) .
我也看到了使用"type"属性的示例(在CouchDB示例中) . 当然,这听起来像是一种可行的方法 . 它是最好的吗?我没有't got a clue. Certainly in MongoDB you'在数据库中使用单独的集合,使得type属性完全无意义 . 但在CouchDB中......也许这是最好的 . 其他选择?每种类型的文件都有单独的数据库?这似乎有点循环,所以我只是我 . 也许还有更好的东西 .
我意识到我已经知道了 . 我的观点是这一点 - 我认为由我们来试验我们正在使用的工具,随着时间的推移,好的想法将会传播并成为最佳实践 . 我只是觉得你在游戏中要求得太早 .