我们该如何设计数据库(二)
2013-07-01 21:33
295 查看
本篇文章旨在讨论如何抽象(以用户作为抽象的例子),并提出一些解耦的思路。详细请见下文
最近公司要开发新系统,基本决定使用ORM(高层还在犹豫,担心效率问题)。既然使用了ORM,那么自然而然的就想到了用面向对象的思想来设计数据库。
本篇文章旨在讨论如何抽象(以用户作为抽象的例子),并提出一些解耦的思路。
我也是第一次在实际项目中使用面向对象的思想来设计数据库,写下这篇博客,也是希望与大家多多交流。
正文开始
首先来需求分析
我们的系统有前台和后台,前台用户有: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十次二十次的,改动起来十分费力)。
具体怎么去解耦,这个问题相当相当的深奥,就不敢在这班门弄斧了。
最近公司要开发新系统,基本决定使用ORM(高层还在犹豫,担心效率问题)。既然使用了ORM,那么自然而然的就想到了用面向对象的思想来设计数据库。
本篇文章旨在讨论如何抽象(以用户作为抽象的例子),并提出一些解耦的思路。
我也是第一次在实际项目中使用面向对象的思想来设计数据库,写下这篇博客,也是希望与大家多多交流。
正文开始
首先来需求分析
我们的系统有前台和后台,前台用户有: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十次二十次的,改动起来十分费力)。
具体怎么去解耦,这个问题相当相当的深奥,就不敢在这班门弄斧了。
相关文章推荐
- 我们该如何设计数据库(五)
- 我们该如何设计数据库(三)
- 我们该如何设计数据库(四)
- 我们该如何设计数据库(二)
- 我们该如何设计数据库(三)(续)(1)
- 我们该如何设计数据库(三)
- 我们该如何设计数据库:“普通——文艺——二逼”的区别
- 我们该如何设计数据库(五)
- 我们该如何设计数据库(三)(续)
- 我们该如何设计数据库(三)(续)(2)
- 我们该如何设计数据库
- 我们该如何设计数据库(四)
- 我们该如何设计数据库(四)
- 我们该如何设计数据库(一)
- 我们该如何设计数据库
- 我们该如何设计数据库(三)
- 我们该如何设计数据库(五)
- 在oracle下我们如何正确的执行数据库恢复
- 同时10万个事务在线,读写频繁,数据库该如何设计
- 如何设计数据库(2)