问题一:是否collection越少越好,尽量把关系数据库中分表表示的关系嵌套进文档里?
问题二:如果这样的话,一句SQL能搞定的复杂查询,mongodb也许要查询多次。mongodb的查询速度是否还比sql数据库快?
问题三:那mongodb的优势体现在哪?超大规模数据的mapreduce?方便拓展?
我来举个栗子吧:
假设mysql中是这样的(意思意思):
authors (
int id,
char name,
int age,
char email
)
articles (
int id,
char title,
char content,
long viewCount,
int author_id
)
那么MongoDB中就可能是这个样子:
- 只有一个authors collection
author {
_id: new ObectID("blublublu"),
name: 'portwatcher',
age: '19',
email: 'root@pwhack.me',
articles: [{
title: 'you guess',
content: 'I am content',
viewCount: 52345
}, ...]
}
问题来了,如果我要单独查出所有作者的文章,并按浏览量来排序,要如何做?
- 于是有了第二种设计方法,这也是nosql = not only sql的体现。有authors和articles两个collection
author {
_id: new ObectID("blublublu"),
name: 'portwatcher',
age: '19',
email: 'root@pwhack.me'
}
article {
_id: new ObjectID("lalalala"),
title: 'you guess',
content: 'I am content',
viewCount: 52345,
author_id: 'blublublu'
}
现在的问题是,如果我要把文章和作者的名字一起返回要怎么办?
1. 是不是要查两次,连两次?如果连一次的话,有一些paas是不支持的(比如说bae,亲测不支持)。这样是否有失优雅?
2. 如果在article里存一份author.name的话,当某个作者改了名字,文章显示的作者名将无法更新,如果硬要一起更新,开销是否太大?
3. DBRef何时用比较合适?在这里,要怎么用?
在这里栗子中,总结一下我们需要的东西:
- 所有作者旗下的文章可以全部聚合返回,并按某种方式排序
- 文章可以和与之匹配的作者名一起返回
- 作者可以编辑自己的资料
- 文章和作者都可以单独插入
可能比较啰嗦,大家谅解。
要是有人能总结一下mongodb数据库设计的一些原则就更好了~
mongodb不是rdbms。你尽可以随意发起任何select类型查询。比如
mysql,这样你就是疯了。mongodb,这样,很好。
你要根本的观念上认为:mongodb是绝对有别于MySQL的。
当然,不可否认的是,查询越少越好- -#