NoSql数据库设计实体的一些原则

1、有排序需求的属性在设计document的时候要定义一个属性，不能放到contents里面去，否则后期无法实现排序的需求。

2、有频繁检索需求就要为其定义一个属性用来存放其值。不能只存放到contents里面去。或者两个地方都存放。

3、如果有全文检索的需求实体的设计方案：

如果不用第三方的检索工具那就只能是尽量多的将属性存放到conents里面去，外面的用or查询来实现，此时外面不应当有太多属性。

 

NoSql的Collection设计 原则。

1，Collection 有固定的schema。

2，减少字段名的长度。减少存储空间。

3，_id由客户端生成。降低服务端的压力。

4，当单个表数据量在千万级以上时，建议用分表的模式来设计

分表设计要对指定字段进行水平拆分。

注意：分表设计有个前提，就是查询要能按照拆分的规则找到对应的表。不然到时候都不知道去那张拆分的表里面去查询。

 

 

 

4、一对多关系的几种设计

        a、一对很少且不需要单独访问内嵌内容的情况下可以使用内嵌多的一方。最主要的优点就是不需要单独执行一条语句去获取内嵌的内容。最主要的缺点是你无法把这些内嵌文档当做单独的实体去访问，更新不方便，单条数据不能大于16M。是最优先考虑的方式

         eg:人的住址(一个人可能有多个住址)

          User   {_id,name,adress:['','','',......]}

        b、一对多且多的一端内容因为各种理由需要单独存在的情况下可以通过数组的方式引用多的一方的主键。

        eg：parts(零件)、product(产品)一个产品由多个零件组成

        parts 表

           {_id,name,price}

        product 表

           {_id,name,parts:[id1,id2,id3,......]}

        c、一对非常多的情况下，请将一的那端引用嵌入进多的一端对象中。

            好处：查询灵活，扩展性高。

            eg：用户集合 和用户消息集合

        d、双向关联（方便查询，但是更新要改动两个文档，无法保证原子操作）

        e、反范式（冗余many端的数据到one端 或 冗余one端的数据到many端） 冗余那些读取频率远远大于更新频率的字段还是值得的

5、多对多关系的设计

      a、在数量不稳定的实体中存放数量稳定的实体id集合，这样设计的好处是数量不稳定的实体变化时可以不用调整数量稳定的记录的内容。

      注意：在关系型数据库中会设计一张中间表。

      b、相互持有另一方的主键集合。

        eg:Team表和User表

             Team表

                   {temId,teamName,teamMates:[userId1,userId2,UserId3,......]}

             User表

                   {userId,userName,teams:[teamId1,teamId2,teamId3,......]}

 

6、精确利用索引 参考http://wangshirufeng.iteye.com/admin/blogs/2264633

7、前期数据设计不用考虑后期统计报表的需求。实现统计报表功能的时候可以按照统计报表的需求重新设计实体，然后将前期收集到的数据按照一定规则提取到统计报表设计的实体中去，然后在将统计报表中的数据在报表界面显示即可。

 

 注意：MongoDB中 不管数据库如何设计都一定要保证单条数据不能大于16M。

 

相关链接：http://www.jianshu.com/p/bb0caddff60a

                  http://www.cnblogs.com/smileberry/p/4171035.html