上篇博客《我們該如何設(shè)計(jì)數(shù)據(jù)庫(三)》寫出來之后，深感自己寫得不夠清晰，虎頭蛇尾，描述問題用了很多篇幅，而問題的解決方案及其優(yōu)缺點(diǎn)卻是一筆帶過，于是就寫下了這篇博客來負(fù)荊請罪。

示例代碼下載：點(diǎn)擊這里下載 

示例代碼說明見下文

首先讓我們來回顧一下《我們該如何設(shè)計(jì)數(shù)據(jù)庫(三)》中描述的問題：

現(xiàn)在有一個(gè)系統(tǒng)，我們暫時(shí)假設(shè)為學(xué)校選課系統(tǒng)。

系統(tǒng)要按學(xué)校來賣。每個(gè)學(xué)校的選課邏輯都是一樣的，而表中的數(shù)據(jù)有共性，但是也有差異性。比如說基本的Teacher表結(jié)構(gòu)是這樣的：

現(xiàn)在把系統(tǒng)賣給A學(xué)校。A學(xué)校除了的Teacher表除了用戶名和密碼之外，還要儲存老師的FirstName和LastName，那么表結(jié)構(gòu)變化如下：

現(xiàn)在B學(xué)校也買了我們的系統(tǒng)。他們的Teacher表不要FirstName和LastName，但是要儲存教師的工號“Number”，表結(jié)構(gòu)如下：

好，現(xiàn)在我們的問題出來了：怎么去解決這種差異性

大致有3種解決方法

1、表中加冗余

2、增加冗余表

3、model繼承

第一種思路：表中加冗余，在上篇已經(jīng)分析過了，在此就稍微說一下優(yōu)缺點(diǎn)。

優(yōu)點(diǎn)在于簡單：思路簡單，實(shí)現(xiàn)也簡單

缺點(diǎn)在于維護(hù)困難：①如果我們的系統(tǒng)賣了很多所學(xué)校，那么對于系統(tǒng)維護(hù)人員來說，這是一場噩夢 ②違背開閉：每次加字段都要去修改已有Model

第二種思路：增加冗余表

如上一篇文章中徐少俠所言，我們也可以這樣來設(shè)計(jì)，用一張冗余表來儲存差異字段，如圖所示：

FirstName、LastName、Number對應(yīng)擴(kuò)展表內(nèi)的三行。

這樣的好處在于：思路簡單，實(shí)現(xiàn)相比第一種思路復(fù)雜一些，但是也不算復(fù)雜。

缺點(diǎn)在于：①Join 。

②違背開閉：每次加字段都要去修改已有Model。

（徐少俠在留言中也說了缺點(diǎn)：查詢數(shù)據(jù)時(shí)候比較辛苦.只能用在讀寫壓力不高的地方.）

第三種思路：Model繼承

這種方法，比較適合使用ORM，或者說適合有Code First的ORM。

在這里使用的是EF5（EF5推薦環(huán)境是.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基礎(chǔ)表。

那么我們的系統(tǒng)賣給我A學(xué)校，A學(xué)校Teacher表有兩個(gè)自己的差異字段：FirstName,LastName。那么Model就要這樣寫。

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

生成出來的數(shù)據(jù)庫如圖：

然后又把系統(tǒng)賣給了B學(xué)校。B學(xué)校系統(tǒng)的部署是獨(dú)立的。B學(xué)校Teacher表差異字段為Number：

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

生成出來的數(shù)據(jù)庫如圖：

#p#

這樣做的優(yōu)勢在于：

1、使用了OO的思想來設(shè)計(jì)Model，更易于理解與后期維護(hù)。

對于查看類的繼承關(guān)系，VS也提供了很好的支持，比如說你可以這樣看：

你也可以這樣看：

2、更清晰的關(guān)注點(diǎn)分離.

其實(shí)這個(gè)是Code First的好處，讓程序員可以直接從Model寫起，不必關(guān)注數(shù)據(jù)庫中的表結(jié)構(gòu)。

如果您對于使用ORM自生成數(shù)據(jù)庫有疑問，請自行百度"Code First"和"數(shù)據(jù)遷徙"。也歡迎留言討論。

這樣做的缺點(diǎn)在于：

1、依賴ORM

2、違背開閉原則：要修改Namespace來切換Model（詳情見下文）  想要切換Model，要修改一處地方（見下文），雖然修改很少，但還是讓人不爽。

3、違背了第三范式：

如Contact，根據(jù)第三范式應(yīng)該獨(dú)立作為一個(gè)表，但是這里卻是寫入了Teacher表中。

也的確有無數(shù)人——朋友，同事，網(wǎng)友——吐槽過我對于第三范式的違反，但是我還是堅(jiān)持：嚴(yán)格的一對一關(guān)系，就是應(yīng)該寫到各個(gè)表中，而不是獨(dú)立作為一個(gè)表。

違反第三范式的好處在于：更少的Join。

而壞處在于：如果要修改，則要修改很多地方。例如Teacher和Student都有Contact，那么如果Contact要加一列Fax，那么要修改兩處地方，這可能帶來額外的錯(cuò)誤。但是這個(gè)缺點(diǎn)因?yàn)槭褂昧薓odel繼承，將不再那么明顯：修改Contact接口，然后修改實(shí)現(xiàn)了Contact接口的Teacher與Student的Model；因?yàn)橛兄悄芴崾镜拇嬖冢@樣不會出錯(cuò)。

為了方便理解，我上傳了源代碼：點(diǎn)擊這里下載

請用VS2010打開，VS2008我不確定能不能運(yùn)行。請確保有本地?cái)?shù)據(jù)庫的權(quán)限。

打開之后直接運(yùn)行，會在本地?cái)?shù)據(jù)庫生成DBaccess.B.Context名字的數(shù)據(jù)庫。

在程序中我沒有寫數(shù)據(jù)遷徙，所以如果您修改了Model，要把之前生成的數(shù)據(jù)庫刪掉之后再運(yùn)行；直接運(yùn)行會報(bào)錯(cuò)。

如果想切換Model，將“Test”中的using Model.B改為using Model.A即可。

這也意味著切換數(shù)據(jù)庫要修改命名空間。對于這個(gè)問題我還沒有好的解決辦法。本來是想用反射工廠來解決這個(gè)問題（代碼中未實(shí)現(xiàn)的ModelFactory），但是反射出來的是Object，要As了之后才能用。

如果有哪位大牛有解決辦法，求告知，小弟在此跪謝。

現(xiàn)在實(shí)現(xiàn)了ModelFactory，使用了預(yù)編譯指令來選擇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 即可。

就此擱筆

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