NoSQL最佳实践

NoSQL数据库,OODB或其他可能存在的缩略语的最佳实践是什么？

例如,我经常看到一个字段"类型"用于决定客户端(应用程序)应该如何解释DB文档(在couchDB/mongoDB术语中).

如果适用,请使用PHP作为参考语言.阅读:我也对如何在客户端最好地处理这些数据感兴趣,而不仅仅是严格的DB结构.这实际上意味着我也在为SQL DB(活动记录,数据映射器等)寻找类似"ORM"的模式.

不要犹豫,说明这样的数据库和PHP 5.3的新功能如何最好地协同工作.

我认为目前,NoSQL数据存储的整个概念和文档数据库的概念是如此新颖,与驱动关系存储的既定想法不同,目前很少(如果有的话)最佳实践.

我们现在知道,将数据存储在CouchDB(或任何其他文档数据库)中的规则与关系数据的规则有很大不同.例如,实际上,3NF的标准化和瞄准并不是人们应该努力的事实.一个常见的例子是一个简单的博客.

在关系存储中,每个"Posts","Comments"和"Authors"都有一个表.每个作者都有很多帖子,每个帖子都会有很多评论.这是一个运行良好的模型,可以很好地映射到任何关系数据库.但是,在docDB中存储相同的数据很可能会有很大不同.你可能有类似Post文档的集合,每个文档都有自己的作者和嵌入的评论集合.当然,这可能不是你能做到的唯一方法,而且它有点妥协(现在查询单个帖子很快 - 你只做一个操作并把所有东西都拿回来了),但你无法保持作者和帖子之间的关系(因为它都成为帖子文档的一部分).

我也见过使用"type"属性的例子(在CouchDB示例中).当然,这听起来像是一种可行的方法.它是最好的吗？我没有线索.当然,在MongoDB中,您将在数据库中使用单独的集合,使类型属性完全无意义.但在CouchDB中......也许这是最好的.其他选择？每种类型的文件都有单独的数据库？这似乎有点循环,所以我自己倾向于"类型"解决方案.但那只是我.也许还有更好的东西.

我意识到我在这里做了很多絮絮叨叨,说的很少,很可能没有你不知道的.我的观点是这一点 - 我认为由我们来试验我们所获得的工具和我们正在合作的数据,随着时间的推移,好的想法将会传播并成为最佳实践.我只是觉得你在游戏中要求得太早.

"NoSQL"应该更多地关注构建数据存储区以遵循您的应用程序要求,而不是构建应用程序以遵循某种结构 - 这更像是传统的SQL方法.

不要仅仅因为"放弃关系数据库"; 只有你的应用真的需要这样做.