MongoDB 数据模型（3/5）三部曲一、建立基础文档模型

文档模型设计之一：建立基础文档模型

---

• 根据概念模型或业务需求推导出逻辑模型 - 找到对象

  • Contact 联系人信息
    

  • Group 分组
    

  • Address 地址（多个）
    

  • Portrait 头像
    

• 列出实体之间的关系（及基数） - 明确关系

  • 一个联系人（Contact）有一个头像（Portraits）1 : 1

    • 1 : 1 关系建模

    • 基本原则

      • 一对一关系以内嵌为主；

      • 作为子文档 或 直接在顶级；

      • 不会涉及到数据冗余；

      • 例外情况：内嵌后导致单个文档大小超过16MB；

      • # 示例
        Contacts 
        	name: "Tom"
        	company: "TAPDATA"
        	title: "CTO"
        	portraits: { # 此处内嵌
        		mimetype: xxx
        		data: xxx
        	}
        

  • 一个联系人可以有多个地址（address）1 : N

    • 基本原则

      • 一对多关系同样以内嵌为主；

      • 用数组来表示一对多；

      • 不涉及到数据冗余；

      • 例外情况：内嵌后导致文档大小超过16MB；数组长度太大（数万或更多）；数组长度不确定；

      • # 示例
        Contacts 
        	name: "Tom"
        	company: "TAPDATA"
        	tilte: "CTO"
        	portraits: {
        		mimetype: xxx
        		data: xxx
        	}
        	addresses: [ # 此处内嵌，之后再看长度不确定的情况 TODO
        		{type: home, ...},
        		{type: work1, ...},
        		{type: work2, ...}
        	]
        

  • 一个联系人可以属于多个组，一个组可以有多个联系人 N : N

    • 基本原则

      • 不需要映射表；

      • 一般用内嵌数组来表示一对多；

      • 通过冗余来实现 N-N；

      • 例外情况：内嵌后导致文档大小超过16MB；数组长度太大（数万或更多）；数组长度不确定；

      • # 示例
        Contacts
        	name: "Tom"
        	company: "TAPDATA"
        	titile: "CTO"
        	portraits: {
        		mimetype: xxx
        		data: xxx
        	},
        	addresses: [
        		{type: home, ...},
        		{type: work, ...}
        	],
        	groups: [ # 此处内嵌，mongo中并不是不可以冗余的，有时候鼓励做冗余，在第一阶段做基础模型设计的时候，先把模型构建好然后以后做进一步的优化，这个地方有数组确实会出现多次，以后再来说 TODO
        		{name: "Friends"},
        		{name: "Surfers"}
        	]
        

• 套用逻辑设计原则来决定内嵌方式 - 进行建模

• 完成基础模型构建