NoSQL数据库，OODB或其他可能存在的缩写词的最佳做法是什么？
例如，我经常看到一个字段“类型”用于决定客户端应用程序应该如何解释DB文档（在couchDB / mongoDB术语中）。
如果适用，请使用PHP作为参考语言。阅读：我也对如何在客户端最好地处理这些数据感兴趣，而不仅仅是严格的DB结构。这实际上意味着我也在为SQL DB（活动记录，数据映射器等）寻找类似“ORM”的模式。
不要犹豫，说明这样的数据库和PHP 5.3的新功能如何最好地协同工作。
答案 0 :(得分：38)
我认为目前，NoSQL数据存储的整个概念和文档数据库的概念是如此新颖，与驱动关系存储的既定思想不同，目前很少（如果有的话）最佳实践。
我们现在知道，在CouchDB（或任何其他文档数据库）中存储数据的规则与关系数据的规则有很大不同。例如，实际上，3NF的标准化和瞄准并不是人们应该努力的事实。一个常见的例子就是一个简单的博客。
在关系商店中，每个“Posts”，“Comments”和“Authors”都有一个表。每个作者都有很多帖子，每个帖子都会有很多评论。这是一个运行良好的模型，可以很好地映射到任何关系数据库。但是，在docDB中存储相同的数据很可能会有很大不同。你可能有类似Post文档的集合，每个文档都有自己的作者和嵌入的评论集合。当然，这可能不是你能做到的唯一方法，而且它有点妥协（现在查询单个帖子很快 - 你只做一个操作并把所有东西都拿回来了），但你无法保持作者和帖子之间的关系（因为它都成为帖子文档的一部分）。
我也看到过使用“type”属性的例子（在CouchDB示例中）。当然，这听起来像是一种可行的方法。它是最好的吗？我没有线索。当然，在MongoDB中，您将在数据库中使用单独的集合，使类型属性完全无意义。但是在CouchDB中......也许 最好。其他选择？每种类型的文件都有单独的数据库？这似乎有点循环，所以我自己倾向于“类型”解决方案。但那只是我。也许还有更好的东西。
我意识到我在这里做了很多絮絮叨叨，说的很少，很可能没有你不知道的。我的观点是这一点 - 我认为由我们自己来试验我们已经获得的工具和我们正在合作的数据，随着时间的推移，好的想法将会传播，成为最好的 - 实践。我只是觉得你在游戏中要求得太早。
答案 1 :(得分：7)
“NoSQL”应该更多地关注构建数据存储区以满足您的应用程序需求，而不是构建应用程序以遵循某种结构 - 这更像是传统的 SQL方法。
不要因为“放弃关系数据库”;只有你的应用真的需要它才能做到。