我们该如何设计数据库(三)(续)

数据库 数据库运维
上篇博客《我们该如何设计数据库(三)》写出来之后,深感自己写得不够清晰,虎头蛇尾,描述问题用了很多篇幅,而问题的解决方案及其优缺点却是一笔带过,于是就写下了这篇博客来负荆请罪。

上篇博客《我们该如何设计数据库(三)》写出来之后,深感自己写得不够清晰,虎头蛇尾,描述问题用了很多篇幅,而问题的解决方案及其优缺点却是一笔带过,于是就写下了这篇博客来负荆请罪。

示例代码下载:点击这里下载 

示例代码说明见下文

首先让我们来回顾一下《我们该如何设计数据库(三)》中描述的问题:

现在有一个系统,我们暂时假设为学校选课系统。

系统要按学校来卖。每个学校的选课逻辑都是一样的,而表中的数据有共性,但是也有差异性。比如说基本的Teacher表结构是这样的:

现在把系统卖给A学校。A学校除了的Teacher表除了用户名和密码之外,还要储存老师的FirstName和LastName,那么表结构变化如下:

现在B学校也买了我们的系统。他们的Teacher表不要FirstName和LastName,但是要储存教师的工号“Number”,表结构如下:

好,现在我们的问题出来了:怎么去解决这种差异性

大致有3种解决方法

1、表中加冗余

2、增加冗余表

3、model继承

 

第一种思路:表中加冗余,在上篇已经分析过了,在此就稍微说一下优缺点。

优点在于简单:思路简单,实现也简单

缺点在于维护困难:①如果我们的系统卖了很多所学校,那么对于系统维护人员来说,这是一场噩梦 ②违背开闭:每次加字段都要去修改已有Model

第二种思路:增加冗余表

如上一篇文章中徐少侠所言,我们也可以这样来设计,用一张冗余表来储存差异字段,如图所示:

 

FirstName、LastName、Number对应扩展表内的三行。

这样的好处在于:思路简单,实现相比第一种思路复杂一些,但是也不算复杂。

缺点在于:①Join 。

②违背开闭:每次加字段都要去修改已有Model。

(徐少侠在留言中也说了缺点:查询数据时候比较辛苦.只能用在读写压力不高的地方.)

第三种思路:Model继承

这种方法,比较适合使用ORM,或者说适合有Code First的ORM。

在这里使用的是EF5(EF5推荐环境是.NET 4.5,不过.NET 4也无伤大雅)

  1. public class Identifier  
  2.     {  
  3.         [Key]  
  4.         public int ID { get; set; }  
  5.     }  
  6.  
  7.     public interface Contact  
  8.     {  
  9.         string Phone { get; set; }  
  10.         string Email { get; set; }  
  11.     }  
  12.  
  13.    public class TeacherBase : Identifier, Contact  
  14.     {  
  15.         [StringLength(50)]  
  16.         public string UserName { get; set; }  
  17.  
  18.         [StringLength(50)]  
  19.         public string Pwd { get; set; }  
  20.  
  21.         [StringLength(50)]  
  22.         public string Phone { get; set; }  
  23.  
  24.         [StringLength(50)]  
  25.         public string Email { get; set; }  
  26.     } 

这样就是我们的Teacher基础表。

那么我们的系统卖给我A学校,A学校Teacher表有两个自己的差异字段:FirstName,LastName。那么Model就要这样写。

  1. namespace Model.A  
  2. {  
  3.     public class Teacher : TeacherBase  
  4.     {  
  5.         [StringLength(50)]  
  6.         public string FirstName { get; set; }  
  7.  
  8.         [StringLength(50)]  
  9.         public string LastName { get; set; }  
  10.     }  

生成出来的数据库如图:

然后又把系统卖给了B学校。B学校系统的部署是独立的。B学校Teacher表差异字段为Number:

  1. namespace Model.B  
  2. {  
  3.     public class Teacher : TeacherBase  
  4.     {  
  5.         [StringLength(50)]  
  6.         public string Number { get; set; }  
  7.     }  

生成出来的数据库如图:

#p#

这样做的优势在于:

1、使用了OO的思想来设计Model,更易于理解与后期维护。

对于查看类的继承关系,VS也提供了很好的支持,比如说你可以这样看:

你也可以这样看:

2、更清晰的关注点分离.

其实这个是Code First的好处,让程序员可以直接从Model写起,不必关注数据库中的表结构。

如果您对于使用ORM自生成数据库有疑问,请自行百度"Code First"和"数据迁徙"。也欢迎留言讨论。

这样做的缺点在于:

1、依赖ORM

2、违背开闭原则:要修改Namespace来切换Model(详情见下文)  想要切换Model,要修改一处地方(见下文),虽然修改很少,但还是让人不爽。

3、违背了第三范式:

如Contact,根据第三范式应该独立作为一个表,但是这里却是写入了Teacher表中。

也的确有无数人——朋友,同事,网友——吐槽过我对于第三范式的违反,但是我还是坚持:严格的一对一关系,就是应该写到各个表中,而不是独立作为一个表。

违反第三范式的好处在于:更少的Join。

而坏处在于:如果要修改,则要修改很多地方。例如Teacher和Student都有Contact,那么如果Contact要加一列Fax,那么要修改两处地方,这可能带来额外的错误。但是这个缺点因为使用了Model继承,将不再那么明显:修改Contact接口,然后修改实现了Contact接口的Teacher与Student的Model;因为有智能提示的存在,这样不会出错。

为了方便理解,我上传了源代码:点击这里下载

请用VS2010打开,VS2008我不确定能不能运行。请确保有本地数据库的权限。

打开之后直接运行,会在本地数据库生成DBaccess.B.Context名字的数据库。

在程序中我没有写数据迁徙,所以如果您修改了Model,要把之前生成的数据库删掉之后再运行;直接运行会报错。

如果想切换Model,将“Test”中的using Model.B改为using Model.A即可。

这也意味着切换数据库要修改命名空间。对于这个问题我还没有好的解决办法。本来是想用反射工厂来解决这个问题(代码中未实现的ModelFactory),但是反射出来的是Object,要As了之后才能用

如果有哪位大牛有解决办法,求告知,小弟在此跪谢。

现在实现了ModelFactory,使用了预编译指令来选择NameSpace:

  1. #define A  
  2. #if B  
  3. using Model.B;  
  4. using DBaccess.B;  
  5. #endif  
  6. #if A  
  7. using Model.A;  
  8. using DBaccess.A;  
  9. #endif 

若要切换Model,将#define B 改为 #define A 即可。

就此搁笔

原文链接:http://www.cnblogs.com/CrazyJinn/archive/2012/10/10/2716052.html

责任编辑:林师授 来源: 博客园
相关推荐

2013-03-20 11:33:31

2012-04-28 10:07:43

数据库数据库设计

2013-03-20 13:35:12

数据库数据库设计

2013-03-20 11:25:47

数据库数据库设计

2013-03-20 13:25:53

数据库数据库设计

2011-05-19 11:01:14

ERWin数据库设计

2023-10-16 09:00:00

数据库分布式系统

2017-07-06 15:52:22

大数据数据分层数据仓库

2017-03-03 15:23:46

数据库设计范式

2022-06-30 18:17:00

数据集云数据建模计数据仓库

2021-10-03 15:00:44

数据库mysql单机

2020-12-31 05:29:25

数据库Powerdesign建模

2011-04-12 10:59:46

Oracle数据库

2017-11-23 15:06:14

前端数据库开发

2017-11-27 06:01:37

数据库中间件中间层

2015-06-23 13:56:30

数据库设计面向对象

2017-11-30 08:56:14

数据库中间件架构师

2011-08-23 17:45:54

MySQL丢失root密码

2021-04-14 09:00:00

MySQL数据库MongoDB

2022-12-27 08:38:45

关系型数据库设计
点赞
收藏

51CTO技术栈公众号