MongoDB数据建模小案例

MongoDB数据建模小案例

朋侪圈品评内容管理

需求

外交类的APP需求，一样寻常都会引入“朋侪圈”功能，这个产物特性有一个非常紧张的功能就是品评体系。

先整理下需求：

  

• 这个APP盼望点赞和品评信息都要包罗头像信息：   
     
  
  • 点赞列表，点赞用户的昵称，头像；   
    
  • 品评列表，品评用户的昵称，头像；   
    
  
  

  

• 数据查询则相对简单：   
     
  
  • 根据分享ID，批量的查询出10条分享里的全部品评内容；   
    
  
  

建模

欠好的计划

跟据上面的内容，先来一个非常非常"淳厚"的计划：

1. {
3.   "_id": 41,
5.   "username": "小白",
7.   "uid": "100000",
9.   "headurl": "http://xxx.yyy.cnd.com/123456ABCDE",
11.   "praise_list": [
13.     "100010",
15.     "100011",
17.     "100012"
19.   ],
21.   "praise_ref_obj": {
23.     "100010": {
25.       "username": "小一",
27.       "headurl": "http://xxx.yyy.cnd.com/8087041AAA",
29.       "uid": "100010"
31.     },
33.     "100011": {
35.       "username": "mayun",
37.       "headurl": "http://xxx.yyy.cnd.com/8087041AAB",
39.       "uid": "100011"
41.     },
43.     "100012": {
45.       "username": "penglei",
47.       "headurl": "http://xxx.yyy.cnd.com/809999041AAA",
49.       "uid": "100012"
51.     }
53.   },
55.   "comment_list": [
57.     "100013",
59.     "100014"
61.   ],
63.   "comment_ref_obj": {
65.     "100013": {
67.       "username": "小二",
69.       "headurl": "http://xxx.yyy.cnd.com/80232041AAA",
71.       "uid": "100013",
73.       "msg": "good"
75.     },
77.     "100014": {
79.       "username": "小三",
81.       "headurl": "http://xxx.yyy.cnd.com/11117041AAB",
83.       "uid": "100014",
85.       "msg": "bad"
87.     }
89.   }
91. }

复制代码

可以看到，comment_ref_obj与praise_ref_obj两个字段，有非常重的关系型数据库陈迹，推测，这个体系之前应该是放在了平常的关系型数据库上，大概计划者被关系型数据库的影响较深。而在MongoDB这种文档型数据库里，实际上是没有须要如许去计划，这种建模只造成了多于的数据冗余。

别的一个标题是，url占用了非常多的信息空间，这点在压测的时间会有表现，带宽会过早的成为瓶颈。同样username信息也是云云，此类信息相对来说是全局稳固的，根本不会做厘革。而且这类信息跟随品评一起在整个APP中流转，也无法处理惩罚”用户名修改“的需求。