在《我们该如何设计数据库（二）》中，园友Jacklondon Chen提出了一些问题，大致如下：
“man/woman应该设计在同一张表中。 用户表大多都设计成一个表。连分 administrator 和 user 都不应该。”
我想还是因为我举例太随意，因为博文中Man和Woman只有4个差异属性：HasCar\HasHouse\HasMoney，以及IsBeauty。
其实对于这个问题我无力吐槽什么，简单的说说吧：假设为Man用户实现的是一个征婚系统，而Woman用户实现的是一个选美系统。这么说应该能理解Man和Woman的不能并同一张表的原因了吧。
废话说完，正文开始
现在有一个系统，我们暂时假设为学校选课系统。有两类用户Teacher和Student，还有一张Curriculum表是课程总表，来储存学校一共有哪些课程，每门课的学分什么的。然后一个老师，一门课程和多名学生，就可以开始上课了。
表结构如下图：
逻辑很简单，一目了然。
但是问题在于，我们的系统要按学校来卖。每个学校的选课逻辑都是一样的，而表中的数据有共性，但是也有差异性。比如说基本的Teacher表结构是这样的：
现在把系统卖给A学校。A学校除了的Teacher表除了用户名和密码之外，还要储存老师的FirstName和LastName，那么表结构变化如下：
现在B学校也买了我们的系统。他们的Teacher表不要FirstName和LastName，但是要储存教师的工号“Number”，表结构如下：
好，现在我们的问题出来了：怎么去解决这种差异性。
最简单的思路莫过于表中加冗余字段。比如说将表设计成这样：
如果我们的系统只卖两三个学校，这样是可行的。但是打个比方，我们的系统卖了30所学校，每个学校有一个自己的差异字段，那么这个表就要有30个冗余字段来应对这种差异性。且不说每次加冗余都要改动系统，且不说冗余多了浪费空间降低传输效率，光说怎么维护这些冗余，我就已经觉得是灾难了：Teacher表有差异字段，其他表也会有。假设一个中型系统，60张表，其中30张实体表30张关系表不算过分吧。那么总共要维护 30（表数量）*30（冗余数量）= 900 个差异字段。
第二个想法是建立一张冗余表来储存差异。这种其实和表中加冗余异曲同工，就不多加分析了，留给大家自己思考。
第三个想法是建立不同的数据库。其实本来每个学校的数据库就是不同的，唔……怎么说呢，A学校自己的数据库中的表，存的是A学校自己的特有字段，B学校存B学校的特有字段。两者之间并无关系，然后Model用l继承的思路来设计（详见上一篇文章），通过配置文件来选择恰当的数据库和其对应的Model。
是的，这种方法挺好的，唯一的不足可能就是比较依赖于ORM——使用ORM来生成数据库，以及T-SQL语句。
如果您是一个关系型数据库的重度爱好者，那么这篇文章到这就结束了，下面的东西不会对您胃口的。
众所周知，因为大量使用了反射，ORM的效率不是那么的高，而且本身关系型数据库的可拓展性也不是那么的好。
作为一个激进的开发者，我一直希望在项目中尝试NoSql。
下面的一篇文章我会讲解如何用MongoDB来解决前文描述的差异性问题，敬请期待。
顺便附上一个小测试：在.net 4环境下分别插入5W条数据，分别是EF5、Nhibernate、ADO.Net向Sql server 2008插入，以及MongoDB官方驱动向MongoDB插入。
EF耗时:00:00:25.4972758
ADO.NET耗时:00:00:23.8307860
NHibernate耗时:00:00:26.0199898
MongoDB耗时:00:00:01.9474134
在这里，EF每次插入1000条数据（批量插入），其他方式都是单条插入；NHibernate关闭了一级缓存；
MongoDB使用的是“离弦之箭”的插入方式。
MongoDB使用的是安全的插入模式（不会丢失数据）。
原文链接：http://www.cnblogs.com/CrazyJinn/archive/2012/09/25/2701284.html
