NoSQL 数据库、OODB 或可能存在的任何其他首字母缩略词的最佳做法是什么？
例如，我经常看到一个字段“类型”用于决定客户端(即应用程序)应如何解释 DB 文档(在 couchDB/mongoDB 术语中)。
在适用的情况下，使用 PHP 作为引用语言。阅读:我也对如何在客户端最好地处理此类数据感兴趣，而不仅仅是严格的数据库结构。这实际上意味着我还在为 SQL DB(事件记录、数据映射器等)寻找诸如“ORM”之类的模式。
不要犹豫，就这样的数据库和 PHP 5.3 的新功能如何最好地协同工作发表声明。
最佳答案
我认为，目前，NoSQL 数据存储和文档数据库概念的整体理念非常新颖，与驱动关系存储的既定理念不同，因此目前几乎没有(如果有的话)最佳实践。
此时我们知道，在 CouchDB(或任何其他文档数据库)中存储数据的规则与用于关系数据库的规则大不相同。例如，规范化和针对 3NF 的目标几乎是一个事实，而不是人们应该努力争取的事情。一个常见的例子是一个简单的博客。
在关系存储中，“帖子”、“评论”和“作者”各有一个表。每个作者会有很多帖子，每个帖子会有很多评论。这是一个运行良好的模型，并且可以很好地映射到任何关系数据库。但是，在 docDB 中存储相同的数据很可能会大不相同。您可能会拥有类似 Post 文档的集合，每个文档中都嵌入了自己的 Author 和 Comments 集合。当然，这可能不是您可以做到的唯一方法，这在某种程度上是一种妥协(现在查询单个帖子很快 - 您只需执行一次操作即可获取所有内容)，但您无法维护作者和帖子之间的关系(因为它都成为帖子文档的一部分)。
我也看到过使用“类型”属性的示例(在 CouchDB 示例中)。当然，这听起来是一种可行的方法。它是最好的吗？我没有头绪。当然，在 MongoDB 中，您会在数据库中使用单独的集合，这使得 type 属性完全是无稽之谈。不过在 CouchDB 中……也许这 是 最好的。其他选择？每种类型的文档都有单独的数据库？这似乎有点循环，所以我自己倾向于“类型”解决方案。但这只是我。也许有更好的东西。
我意识到我在这里闲聊了很多，说的很少，很可能是你不知道的。不过我的观点是——我认为这取决于我们对我们拥有的工具和我们正在使用的数据进行试验，随着时间的推移，好的想法将被传播并成为最好的——实践。我只是觉得你在游戏中问得太早了。
关于mongodb - NoSQL 最佳实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2170152/