?????可能您會問，樹的系列還差第三篇沒有寫呢，怎么就又說數據庫設計了？因為如果寫第三篇的話，那么就涉及到了權限，而權限里面又涉及到了人員，這些信息都是存放在表里面的，所以就只好先說數據庫設計了。

（說到這里，我也感覺到了，以數據庫為主的話，各方面的關聯確實比較密切，不容易分割，如果使用面向對象的話，也許能夠更清晰的分割開來吧。）

????? 前提：這里討論的還是以數據為主的項目，數據都需要保存在關系型數據庫里的項目。

?????

????? 正文：

?????當您接手一個項目后，打開SQL Server 一看，靠，五、六百個表，暈倒。打開數據庫的設計圖一開，一大堆的表擠在一起，各種連線錯綜復雜的一團，這絕對可以和迷宮相媲美了。爬起來再暈倒。

?????您想改變這種情況，于是您選擇了面向對象，希望面向對象能夠解決這種亂糟糟的情況，我不知道您成功了沒有。

?????而我的思路是：數據庫的事情還是找自己人來解決吧，不要麻煩外人了。所以我想進行一點小小的“改革”—— 增加幾個概念，從另一個角度來看表之間的關系。

【表關系的圖】

?

【以人員管理為例的說明】

?????表組 ：就是一組表，一些相關的表組合在一起，組成一個組，共同表達一項事物。比如這里要說的人員管理，和人員比較密切的若干各表和在一起，組成了 人員表組 。類似的還有以后會說的組織機構、權限管理等。

????? 表群 ：一個大模塊需要的表、表組，組合在一起，就是一個表群。

????? 相關表 ：有關聯的表。
????? 不相關表 ：沒有直接關系的表。比如人員表和產品分類表。

?????主表、跟隨表、邊界表、描述表。

????? 主表 ：主要的表，核心表，可以獨立存在。比如這里的人員自然信息表。是一個表組的“代表”。
????? 跟隨表 ：跟著主表走的表，不能獨立存在。比如這里的聯系信息表、工作經歷表等。由于跟隨表只記錄主表的ID，而只看ID是不知道到底是誰的信息，所以說不能獨立存在。?????

????? 邊界表 ：就是承上啟下的意思，用于多對多的表的連接。也是連接兩個表組的表。比如這里的“人員——角色表”、“人員——組織結構表”。

????? 描述表 ：描述一個具體情況的表，比如省份表、學歷表、產品分類表等。也就是字典信息表。

????? 命名習慣 ：我的命名習慣是加前綴。表名前面要加上大模塊的前綴（或者表組的前綴），后面才是表名。因為在SQL Server 的企業管理器里面可以按照表名來排序，這樣相關的表就會排在一起，看起來方便一些。

?????視圖名的前面要加上視圖的標識(前綴)，我習慣加上“V_”來和表名相區分。

?????存儲過程的前面最好也加上一個存儲過程的標識(前綴)，我習慣加上“Proc_”。

????? 注意： 存儲過程最好不要使用“sp_”，“xp_”，“dt_”開頭。因為系統提供的存儲過程和擴展存儲過程都是以這些開頭的，在尋找存儲過程的時候，如果是這些開頭的話，那么會先到系統的存儲過程里面去查找。另外，加這樣的前綴也不容易和系統的存儲過程相區分。

?

?????這樣我們在總體設計的時候，只需要關注的“表組”（其實也就是“主表”）和表組之間的關系就可以了，描述表、邊界表都可以忽略，而跟隨表大多數也可忽略了，在需要的時候看一下就可以了。主表是一個表組的“代表”，所以一個表組里面只能有一個主表。

?????這樣在打開設計圖的時候， 映入眼簾的就不是一大堆表的，而是幾個（或者十幾個）表組 。如果是很大的項目的話，那么看到的是幾個表群。只有當需要關注細節的時候才去看一個表組里的有哪些表，再進一步看細節的話，才去看表里面的字段。

（雖然現在面向對象很流行，但是我還是習慣先設計數據庫，以數據庫為中心，圍繞數據庫轉。當然這樣的話，就給自己做了一個限制，只能夠做那些需要數據庫的項目，不過這樣的項目也有很多呀，夠我做的了，呵呵。）

?

?????很多項目都需要有一個人員管理的模塊，這個可以說是一個基礎吧，無論是OA、CMS、ERP、企業定制等都是需要的，網站里也會有一個會員系統吧。所以我就從這個比較基礎的開始吧。（請看上面的圖）

?????人員管理，首先要有姓名、性別、出生日期等信息的表，我們把這個表叫做“人員自然信息”，這里的字段的特點就是“唯一”，一對一的，自然里的，基礎的，基本的就放在這里面。這個也就是人員表組的主表。

?????有了自然信息后，需要有一個聯系信息，這個表也是一對一的。固定電話、手機、QQ、MSN、Email等。這是一個跟隨表，跟著主表（人員自然信息）走的表。

?????然后就是學習經歷、工作經歷等一對多的表。這些也都是跟隨表。

?????最后是登陸賬號。而“人員——角色表”、“人員——組織結構表”，這個就是“邊界表”，就是聯系多對多的一個表，他負責“聯系”兩方面的表。

?????這么多的表如何來關聯呢，很簡單都只用EmpID來關聯。

?

?????您可能會問如果一個人有兩個手機號碼，而表里面只有一個手機號的字段，那么要如何解決方式呢？有兩種方式：一是不管有多少手機號，都放在一個字段里面，用逗號來分割就可以了。另一個就是增加一個字段，分別叫做“手機號1”、“手機號2”。您可能會說這種方法都不合理，應該把聯系方式表改成一對多的形式。我覺得改成一對多就更麻煩了。

?

總結：

?????一對一、一對多、多對多，主從表，這樣的分析完全是由關系型數據庫本身的特點來做的，一點業務邏輯都沒有考慮進去。

?????而我的上面的方法是把業務邏輯“摻和”進來了，從業務邏輯的角度來分析數據結構，做劃分、做分組。

?????我想，大家或多或少都是這么做的吧，我這里只是把這種方式給“挑明了”。歡迎大家的看法。