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

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

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

示例代码说明见下文

 

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

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

系统要按学校来卖。每个学校的选课逻辑都是一样的，而表中的数据有共性，但是也有差异性。比如说基本的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也无伤大雅）

    public class Identifier
    {
        [Key]
        public int ID { get; set; }
    }

    public interface Contact
    {
        string Phone { get; set; }
        string Email { get; set; }
    }

   public class TeacherBase : Identifier, Contact
    {
        [StringLength(50)]
        public string UserName { get; set; }

        [StringLength(50)]
        public string Pwd { get; set; }

        [StringLength(50)]
        public string Phone { get; set; }

        [StringLength(50)]
        public string Email { get; set; }
    }

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

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

namespace Model.A
{
    public class Teacher : TeacherBase
    {
        [StringLength(50)]
        public string FirstName { get; set; }

        [StringLength(50)]
        public string LastName { get; set; }
    }
}

生成出来的数据库如图：

 

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

namespace Model.B
{
    public class Teacher : TeacherBase
    {
        [StringLength(50)]
        public string Number { get; set; }
    }
}

生成出来的数据库如图：

 

这样做的优势在于：

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：

 

#define A
#if B
using Model.B;
using DBaccess.B;
#endif
#if A
using Model.A;
using DBaccess.A;
#endif

 

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

 

 

就此搁笔

 

 

PS：12306是一群小学生作的么？

再PS：有园友批评我“手中有个锤子，看到什么都是钉子”，说的是我什么问题都想用ORM来解决。关于锤子问题我不否认，但是那个锤子是NOSQL，只是现在还没写到而已