在《我们该如何设计数据库(二)》中,园友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.shufengxianlan.com/qtweb/news32/293682.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联