小亮浅谈mongo

Mongo数据库的设计要遵循的规则

l  前言

随着现在分布式数据库的崛起,部分的项目的后台已经渐渐的时候这种非关系型的数据库来设计了,那么这种数据库有什么样的有点呢?

(1)     大家都知道后期的数据库将是非常庞大的一个东西,好多的项目都是使用的关系型的数据库来支撑的,他们无疑是一个非常不错的选择,要考虑到后期程序的运行的效率,那时候大家就会考虑使用程序来实现数据库的分布(或者使用非常好的服务器来支撑),但是后期发现的mongo确实可以帮助大家解决这种分布式所带来的问题,mongo在设计出就是考虑到了这些问题,你只需建立一些引用的关系方可实现。

(2)     Mongo是一种面向对象的数据库，所以很适合面向对象的这种语言来使用(必须C#,java等高级语言),它原本只是被人们用来做缓存使用的数据库,就和android的内置的sqlite一样,但是这并不会影响它的强大的锋芒,他们发现他们设计的这种思想非常的难得,就加以发展,也就是我们现在看到的mongoDB。

(3)     强大的查询功能,mongo中的查询可以使用Pattern来查询,数据存储的时候可以存储json格式的数据,当然咋们查询的时候就可以xx.xx.xx=xxx这样的格式来匹配json格式的字段了。

(4)     Mongo由于是非关系型的数据库,所以字段的存储也是非常的随便的,关系型数据库在设计的时候一般就会把所有的字段都确定好了,但是mongo不一样,在设计的时候前后台约定好哪些字段为必要的字段和类型。那么前台便可以很灵活的传一些字段到后台来。

(5)     但是mongo也有很多的缺点的,相对关系型数据库mongo的设计非常的复杂,甚至一个表中会出现多个表的引用而且这些引用都是多对多的关系，然而关系型数据库设计的时候通常会把多对多的关系转化为两个一对多来实现的。

(6)     Hibernate框架，比如我们在开发jsp的一些项目的时候，可以使用到hibernate框架来影射数据库中的表与表之间的关系，但是mongo是做不到的，所以当设计到操作到多张表的时候就要自己动手敲代码了。(我做多写一个API写了300行涉及到了五张表联合操作,好多方法还封装了)。

(7)     Mongo的存储非常的随便也导致了一些缺点，插入数据的时候字段可以随便的加没有任何的约束。

l  设计时的注意点.

我认为mongo的灵活性非常的强大，但是再设计数据库的时候还是要遵循一定的规则的。

(1)     当需求提出来的时候，关系型数据库是通过主外键的关系来关联多张表的，虽然mongo中没有明显的主外键的关系但是我们可以通过对数据库的设计来实现这样的关系。

Example：一个团队下面可以有多个业务但是一个业务只能归属一个团队。

我们可以这样设计，在业务表中加一个字段teamId类型为DBRef引用的类型，而团队的表中加一个字段taskId类型是一个List<DBRef>的类型，这样就可以体现了团队和业务是一对多的关系了。

扩展：如果团队和业务的关系是多对多的关系的话，我们可以将业务中的teamId也换成List<DBRef>来方团队ID的引用集合。

(2)     关系型数据库在存放数据的时候尽量的做到分开来存放，但是mongo却不是这样的，设计的时候最好是遵循执行增加操作的时候繁琐一点没关系，但是查询的时候一定要简单，毕竟查询是sql语句中最长使用的。

 (3)  mongodb replica set让mongodb更加的云化，查询的速度大大提高。

举个例子：当我们在美国亚马逊上部署了环境，国内去访问这个服务器的事情速度可能受很大的影响，那我们在北京再部署一个mongodb服务器，让北京的和亚马逊 的配置为replica set，将亚马逊的配置为主服务器，这样配置有啥好处？

详细的请关注：明天发布。(今天发布超过20篇了)

链接：http://blog.csdn.net/lu467344991/article/details/7538529

(4) mapreduce 提供了更强大的统计功能。

 

还很粗糙，希望大家多提意见，小弟毕将整理。 

未完待续………