我们该如何设计数据库(二)
最近公司要开发新系统，基本决定使用ORM（高层还在犹豫，担心效率问题）。既然使用了ORM，那么自然而然的就想到了用面向对象的思想来设计数据库。
创新互联公司长期为成百上千客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为尉氏企业提供专业的成都网站建设、成都网站制作，尉氏网站改版等技术服务。拥有10多年丰富建站经验和众多成功案例,为您定制开发。
本篇文章旨在讨论如何抽象（以用户作为抽象的例子），并提出一些解耦的思路。
我也是***次在实际项目中使用面向对象的思想来设计数据库，写下这篇博客，也是希望与大家多多交流。
正文开始
首先来需求分析
我们的系统有前台和后台，前台用户有：Man，Woman，SuperMan，SpiderMan与IronMan。后台用户为Administrator。
前台用户都要填写联系方式与地址，然后SuperMan，SpiderMan与IronMan都有Ability。
需求很简单。那么按照这个需求，我们来随手画一个继承关系图。其中V代表抽象类（应该是abstract，画图的时候脑抽想着是virtual就用V开头了，懒得改图了大家凑合着看吧），I代表Interface。如下图：
从图中可以看出，由抽象类Person派生出Administration与抽象类User。类Man与类Womam实现了接口Address与接口Contact，Inhumans则实现了Ability接口。
然后抽象类代码：
- View Code
- public abstract class Person
- {
- public string Username { get; set; }
- public string Password { get; set; }
- }
- public abstract class User : Person
- {
- public string Name { get; set; }
- }
接口代码：
- View Code
- public interface IAddress
- {
- string Address { get; set; }
- }
- public interface IContact
- {
- string Email{get;set;}
- string WorkPhone { get; set; }
- string MobilePhone { get; set; }
- string Fax { get; set; }
- }
***是Man类和Woman类：
- View Code
- public class Man : User, IContact, IAddress
- {
- public string Address { get; set; }
- public string Email { get; set; }
- public string WorkPhone { get; set; }
- public string MobilePhone { get; set; }
- public string Fax { get; set; }
- public bool HasCar { get; set; } //如果这三项都为false的话
- public bool HasHouse { get; set; } //这辈子就甭想结婚了
- public bool HasMoney { get; set; } //T T我泪涌
- }
- View Code
- class Woman : User, IAddress, IContact
- {
- public string Address { get; set; }
- public string Email { get; set; }
- public string WorkPhone { get; set; }
- public string MobilePhone { get; set; }
- public string Fax { get; set; }
- public bool IsBeauty { get; set; } //这个为true，一辈子不愁吃喝
- }
代码非常简单。其他几个类限于篇幅就不说那么细了。
那么按照这个model，使用EF Model First来建立数据库，得到的Woman表如下：
那么接下来就是重点了：为什么不把Contact和Address分表储存。这样与Man表、Woman表写在一起的话，出现改动（如新增一种联系方式），会不会非常痛苦。
如果不是使用ORM，那么这个改动的确是很痛苦；但是如果使用了（这里默认使用的ORM可以从Model生成/改动数据库），那么这个改动是没什么大不了的了，只需要修改一下接口定义，然后根据报错去改就好了。至于数据库的变动，就交给ORM去做就OK了。
这样有一个好处，可以在有限的范围内实现解耦，部分减少了关系——若将Contact和Address分表的话，取Woman要Join两次，这看起来没什么大不了的，但是如果放大了看，如果是join十次呢？这样弄出来的东西很难去维护（现在公司老系统就是这样，动不动就join十次二十次的，改动起来十分费力）。
具体怎么去解耦，这个问题相当相当的深奥，就不敢在这班门弄斧了。
当前标题：我们该如何设计数据库(二)
本文URL：http://www.shufengxianlan.com/qtweb/news45/65795.html
网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等
声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联