有关MongoDB数据库设计的问题

问题一:是否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: ‘[email protected]‘,
        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: ‘[email protected]‘
    }

    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数据库设计的一些原则就更好了~

时间: 2024-10-29 19:05:58

有关MongoDB数据库设计的问题的相关文章

MongoDB数据库设计中6条重要的经验法则,part 3

原文:6 Rules of Thumb for MongoDB Schema Design: Part 3 By William Zola, Lead Technical Support Engineer at MongoDB 这篇文章是系列的最后一篇.在第一篇文章里,我介绍了三种针对"一对多 "关系建模的基础方案.在第二篇文章中,我介绍了对基础方案的扩展:双向关联和反范式化. 反范式可以让你避免一些应用层级别的join,但是这也会让更新变的更复杂,开销更大.不过冗余那些读取频率远远大

MongoDB数据库设计中6条重要的经验法则

Part 1 原文:6 Rules of Thumb for MongoDB Schema Design: Part 1 By William Zola, Lead Technical Support Engineer at MongoDB “我有丰富的sql使用经验,但是我是个MongoDB的初学者.我应该如何在MongoDB中针对一对多关系进行建模?”这是我被问及最多的问题之一. 我没法简单的给出答案,因为这有很多方案去实现.接下来我会教导你如何针对一对多进行建模. 这个话题有很多内容需要讨

mongodb数据库设计原则

1.一对很少  one-to-few  可以采用内嵌文档 person集合中 { name:'张三', age:20, address:[ {country:"中国",province:"山西省",city:"长治市"}, {country:"中国",province:"山西省",city:"太原市"} ] } 优点:不需要单独执行一条语句去获取内嵌的内容 缺点:法把这些内嵌文档当做单独

用MongoDB数据库来管理办公系统中文档型的表单和信息——通用流程化应用审批单设计思路(二,续)

1.办公系统中文档的定义 办公系统中的文档就是指对数据不敏感的业务,例如流程中的审批单.信息专栏.数据上报.信息记录等.而对于这些信息的管理,特别是时效性较强的管理记录,仍采用关系型数据库进行管理. (1)流程中审批单 流程中审批单由功能按钮区.特殊功能区.业务表单区.附件区.审批意见区等区域构成,其中,业务表单区理论上包含附件和意见,但是由于附件和意见的业务特殊性,需要单独进行管理,剩下的业务表单就可以看作文档了. 在一些流程审批业务中,业务信息有的是以Excel或word文件等方式专递,这样

关系型数据库与Key-value型数据库Mongodb模式设计对比

MongoDb 相比于传统的 SQL 关系型数据库,最大的不同在于它们的模式设计( Schema Design )上的差别,正是由于这一层次的差别衍生出其它各方面的不同. 我们可以简单的认为关系型数据库由数据库.表(table).记录(record)三个层次概念组成,而在构建一个关系型数据库的时候,工作重点和难点都在数据库表的划分与组织上.一般而言,为了平衡提高存取效率与减少数据冗余之间的矛盾,设计的数据库表都会尽量满足所谓的第三范式.相对的,可以认为MongoDb由数据库.集合(collect

Java精品高级课,架构课,java8新特性,P2P金融项目,程序设计,功能设计,数据库设计,第三方支付,web安全,视频教程

36套精品Java架构师,高并发,高性能,高可用,分布式,集群,电商,缓存,性能调优,设计模式,项目实战,P2P金融项目,大型分布式电商实战视频教程 视频课程包含: 高级Java架构师包含:Spring boot.Spring  cloud.Dubbo.Elasticsearch,Redis.ActiveMQ.Nginx.Mycat.Spring.MongoDB.ZeroMQ.Git.Nosql.Jvm.Mecached.Netty.Nio.Mina.java8新特性,P2P金融项目,程序设计,

基于C#的MongoDB数据库开发应用(2)--MongoDB数据库的C#开发

在上篇博客<基于C#的MongoDB数据库开发应用(1)--MongoDB数据库的基础知识和使用>里面,我总结了MongoDB数据库的一些基础信息,并在最后面部分简单介绍了数据库C#驱动的开发 ,本文继续这个主题,重点介绍MongoDB数据库C#方面的使用和封装处理过程,利用泛型和基类对象针对数据访问层进行的封装处理. 前面介绍到,当前2.2版本的数据库C#驱动的API,支持两种不同的开发接口,一个是基于MongoDatabase的对象接口,一个是IMongoDatabase的对象接口,前者中

数据库设计 Step by Step (1)——扬帆启航

引言:一直在从事数据库开发和设计工作,也看了一些书籍,算是略有心得.很久之前就想针 对关系数据库设计进行整理.总结,但因为种种原因迟迟没有动手,主要还是惰性使然.今天也算是痛下决心开始这项卓绝又令我兴奋的工作.这将是一个系列的文 章,我将以讲座式的口吻展开讨论(个人偷懒,这里的总结直接拿去公司培训新人用). 系列的第一讲我们先来回答下面几个问题 数据库是大楼的根基 大多数程序员都很急切,在了解基本需求之后希望很快的进入到编码阶段(可能只有产出代码才能反映工作量),对于数据库设计思考得比较少. 这

浅析MongoDB数据库的海量数据存储应用

[摘要]当今已进入大数据时代,特别是大规模互联网web2.0应用不断发展及云计算所需要的海量存储和海量计算发展,传统的关系型数据库已无法满足这方面的需求.随着NoSQL数据库的不断发展和成熟,可以较好地解决海量存储和海量计算方面的应用需求.本文重点描述作为NoSQL之一MongoDB数据库在海量数据存储方面的应用. 1 引言NoSQL,全称是“Not Only Sql”,指的是非关系型的数据库.这类数据库主要有这些特点:非关系型的.分布式.开源的.水平可扩展的.原始目的是为了大规模web应用,这