NoSQL 最佳实践 [英] NoSQL best practices

问题描述

NoSQL 数据库、OODB 或可能存在的任何其他首字母缩略词的最佳做法是什么?

What are the best practices for NoSQL Databases, OODBs or whatever other acronyms may exist for them?

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

For example, I've often seen a field "type" being used for deciding how the DB document (in couchDB/mongoDB terms) should be interpreted by the client, the application.

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

Where applicable, use PHP as a reference language. Read: I'm also interested in how such data can be best handled on the client side, not only strictly the DB structure. This means practically that I'm also looking for patterns like "ORM"s for SQL DBs (active record, data mapper, etc).

不要犹豫，就这样的数据库和 PHP 5.3 的新功能如何最好地协同工作发表声明.

Don't hesitate making statements about how such a DB and the new features of PHP 5.3 could best work together.

推荐答案

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

I think that currently, the whole idea of NoSQL data stores and the concept of document databases is so new and different from the established ideas which drive relational storage that there are currently very few (if any) best practices.

此时我们知道，在 CouchDB(或任何其他文档数据库)中存储数据的规则与用于关系数据库的规则大不相同.例如，规范化和针对 3NF 的目标几乎是一个事实，而不是人们应该努力争取的事情.一个常见的例子是一个简单的博客.

We know at this point that the rules for storing your data within say CouchDB (or any other document database) are rather different to those for a relational one. For example, it is pretty much a fact that normalisation and aiming for 3NF is not something one should strive for. One of the common examples would be that of a simple blog.

在关系存储中，帖子"、评论"和作者"各有一个表.每个作者会有很多帖子，每个帖子会有很多评论.这是一个运行良好的模型，并且可以很好地映射到任何关系数据库.但是，在 docDB 中存储相同的数据很可能会大不相同.您可能会拥有类似 Post 文档的集合，每个文档中都嵌入了自己的 Author 和 Comments 集合.当然，这可能不是您可以做到的唯一方法，这在某种程度上是一种妥协(现在查询单个帖子很快 - 您只需执行一次操作即可获取所有内容)，但您无法维护作者和帖子之间的关系(因为它都成为帖子文档的一部分).

In a relational store, you'd have a table each for "Posts", "Comments" and "Authors". Each Author would have many Posts, and each Post would have many Comments. This is a model which works well enough, and maps fine over any relational DB. However, storing the same data within a docDB would most likely be rather different. You'd probably have something like a collection of Post documents, each of which would have its own Author and collection of Comments embedded right in. Of course that's probably not the only way you could do it, and it is somewhat a compromise (now querying for a single post is fast - you only do one operation and get everything back), but you have no way of maintaining the relationship between authors and posts (since it all becomes part of the post document).

我也看到过使用类型"属性的示例(在 CouchDB 示例中).当然，这听起来是一种可行的方法.它是最好的吗?我没有头绪.当然，在 MongoDB 中，您会在数据库中使用单独的集合，这使得 type 属性完全是无稽之谈.不过在 CouchDB 中……也许这 是 最好的.其他选择?每种类型的文档都有单独的数据库?这似乎有点循环，所以我自己倾向于类型"解决方案.但这只是我.也许有更好的东西.

I too have seen examples making use of a "type" attribute (in a CouchDB example). Sure, that sounds like a viable approach. Is it the best one? I haven't got a clue. Certainly in MongoDB you'd use seperate collections within a database, making the type attribute total nonsense. In CouchDB though... perhaps that is best. The other alternatives? Separate databases for each type of document? This seems a bit loopy, so I'd lean towards the "type" solution myself. But that's just me. Perhaps there's something better.

我意识到我在这里闲聊了很多，说的很少，很可能是你不知道的.不过我的观点是——我认为这取决于我们对我们拥有的工具和我们正在使用的数据进行试验，随着时间的推移，好的想法将被传播并成为最好的——实践.我只是觉得你在游戏中问得太早了.

I realise I've rambled on quite a bit here and said very little, most likely nothing you didn't already know. My point is this though - I think its up to us to experiment with the tools we've got and the data we're working with and over time the good ideas will be spread and become the best-practices. I just think you're asking a little too early in the game.

这篇关于NoSQL 最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！