表設計小序

本身經驗雜項：

1.tree表設計，除，id,pid,等加入treepath,有利於快速檢索和直接檢索，感受是二叉尋找，O(2^n)。

2.系統都有權限表，這個是一個比較有名成熟的設計方案，名忘記了。

https://my.oschina.net/u/1052786/blog/701891

3.表不少，通常系統會用到一些公共變量，抽象出字典表。

4.都是，表名也要有意義，分類別管理，不說了。

5.表裏通常都有，主鍵：要有意義，hbase分佈式的話，就知道有意義的主鍵是路徑的檢索依據，計算機的世界都是先找到資源位置再取東西，一直都在努力改進找路的問題。自動增加的主鍵導出時會變，要變就麻煩了。表裏加些默認的字段：insert_time,insert_user,update_time,update_user,is_update(邏輯刪除)。

6.many to many 的能夠拆成 many to one ,one to many的，關聯關係，有的大師說很重要，由於表的設計就是世界的關聯，是，然而咱們系統有關係的也不寫外鍵，都是獨立維護，好處也有，就是性能高，測試開發方便。別的嗎，邏輯容易出數據bug，知道就成。

7.表少（意思是抽象度高點，別來回把數據庫當倉庫和垃圾堆，最後的結果不是不重視，來幾我的都攪攪表都毀了），字段精，那確定是，瞭解越深，考慮越全，抽象越高，效果越好，性能越高，沒有止境。第三範式到如今沒理解在說啥，好像是又不是。

8.系統最基本也要弄個操做日誌表（操做什麼了，IP,時間什麼的），運行日誌表（都有了）。

9.這個好，系統要加入表信息表，就是表說明表（書有目錄，這個能夠類比書的目錄，存的更有用的信息些）誰加了什麼表，幹嗎的都維護上去，都能看見，好處不少了。（id,tab_name,insert_user,insert_time,description）

10.設計表說要減小冗餘，實現字表的列轉行功能，避免子拉到主表。

11.存儲過程能夠改善執行效率，維護時候不太可見，這個不爽。觸發器有點危險，性能有影響。

範式大體理解吧：

概念的單一化，即一個關係表示一個實體。有點Java面對對象的意思。

1NF： 字段是最小的的單元不可再分
2NF：知足1NF,表中的字段必須徹底依賴於所有主鍵而非部分主鍵 (通常咱們都會作到)
3NF：知足2NF,非主鍵外的全部字段必須互不依賴

好像平時也沒注意，都這麼作的。

 

原文及我的註釋：

當您在決定開發一個數據庫管理項目時，最早着手的工做就應是數據庫表結構的設計了。能夠這麼說，表結構的設計是開發數據庫管理項目的基石，一個糟糕的表結構設計，可能會嚴重延誤您的項目開發週期，使您大量的勞動時間爲此付之東流。表結構設計是數據庫邏輯設計的重要組成部分，直接影響到數據庫的性能，因此小編在本文對數據庫（表結構）設計技巧及注意事項作一個講解！

　　1．表名通常以【模塊名稱_具體表名】來實現，同一個模塊的前綴是同樣的。(Oracle大小寫敏感，在ＳＱＬ中能夠不用"_",由於能夠用大小寫一塊兒的寫法。這也是能夠的)

　　2．表名稱不該該取得太長（通常不超過三個英文單詞，不推薦使用中文拼音，總的長度不要超過30個字符）。表名使用英文的緣由，有些項目有英文版的須要，或者這個項目是給外國作的時候，使用英文是基本的要求，應該說這是一個習慣問題，多學一點英文也不是壞事

　　3．不使用tab或tb做爲表前綴（原本就是一個表，爲何還要說明）。

　　4．一些做爲多對多鏈接的表，可使用兩個表的前綴做爲表名：如：用戶登陸表User_Login，用戶分組表User_GroupInfo，這兩個表創建多對多關係的表名爲：User_Group_Relation（關係統一用Relation）。注意一點，主鍵在作其餘表的外鍵時，或者在被其餘表引用時，字段說明和字段名儘可能保持一致，好比發帖表BBS_Topic裏的用戶字段寫成UI_ID,這樣跟用戶信息表User_Info的主鍵UI_ID保持一致，看起來舒服，對應關係很明確，也不容易錯，先後不一致時容易使人費解。

　　5．當系統中有一些少許的，重複出現的值時，使用字典表來節約存儲空間和優化查詢。如地區、系統中用戶類型的代號等。這類值不會在程序的運行期變化，可是須要存儲在數據庫中。通常數據庫中，都有一個數據字典表，用來保存系統所用到的基礎數據，大型的字段表如省份城市區域的字典表，統一以Dictionary_做爲前綴。

　　6．與字段有關，默認的一些特殊字段，不少表中，好比一些業務處理表中，除了添加生成的自動編號ID（通常做爲主鍵用），該記錄建立的時間CreateDate(建立時間),該記錄的建立人CreatBy（注意這裏，沒UI_ID（用戶信息表User_Info的主鍵UI_ID）,由於還有修改人），最後修改人LastEditBy，最後修改時間LastEditDate。（這些能夠直接使用中文字符，而不使用編碼，提升查詢的效率）

　　同時有的時候須要注意，刪除的時候並不真的刪除該記錄，而是添加一個標識位，好比XX_DeleteStaus刪除狀態。1是有效的，0則是無效的。

　　7．在命名錶時，用單數形式表示名稱。例如，使用Employee，而不是Employees。

　　8．數據庫中應創建這樣一個表，就是數據庫自己的字段信息，表的說明，也就是數據庫設計文檔的一個表，方便查詢使用，有什麼不明的能夠直接從數據庫查詢，數據庫文檔丟失，註釋丟失，均可以從新起做用。

　　9．每一個表都應該有一個主鍵，這個主鍵最好是數字，並且是遞增的，有不少表的主鍵用32位字符編碼，這樣作的目的更多的是從安全考慮的。由於字符多時索引時效率低，而使用自增列也不是不多，好比添加主表和從表操做時，主表的主鍵是從表的外鍵，這個時候還有取返回值，而後再添加，不能夠同時添加。主鍵能夠用自定義的規則，大部分用MAX（ID）的作法，也能夠自定義一個序列表，有點像序列，或者用時間的年月日秒具體到毫秒。關於列的命名,建議對數據類型也作一些規範，由於很容易肯定，只有四種主要類型：數字，字符，時間，邏輯值，這些在類型上和長度上均可以定好規範，統一塊兒來。

　　10.基本表及其字段之間的關係,應儘可能知足第三範式。可是，知足第三範式的數據庫設計，每每不是最好的設計。爲了提升數據庫的運行效率，經常須要下降範式標準：適當增長冗餘，達到以空間換時間的目的。

　　11.若兩個實體之間存在多對多的關係，則應消除這種關係。消除的辦法是，在二者之間增長第三個實體。這樣，原來一個多對多的關係，如今變爲兩個一對多的關係。要將原來兩個實體的屬性合理地分配到三個實體中去。這裏的第三個實體，實質上是一個較複雜的關係，它對應一張基本表。通常來說，數據庫設計工具不能識別多對多的關係，但能處理多對多的關係。

　　12.主鍵PK的取值方法，PK是供程序員使用的表間鏈接工具，能夠是一無物理意義的數字串,由程序自動加1來實現。也能夠是有物理意義的字段名或字段名的組合。不過前者比後者好。當PK是字段名的組合時，建議字段的個數不要太多，多了不但索引佔用空間大，並且速度也慢。

　　13.中間表是存放統計數據的表，它是爲數據倉庫、輸出報表或查詢結果而設計的，有時它沒有主鍵與外鍵(數據倉庫除外)。臨時表是程序員我的設計的，存放臨時記錄，爲我的所用。基表和中間表由DBA維護，臨時表由程序員本身用程序自動維護。

　　14．操做日誌表，登陸日誌表，這是數據庫中必備的兩個表，這個記錄也須要作進一步的保存。這個有兩種情形，一是具體到單個字段的操做日誌，二是整個表的操做日誌。

　　常見的幾個表具體說明：操做日誌表Sys_OperateLog、登陸日誌表Sys_LoginLog、系統字典表Sys_Dictionary、系統字典表類型Sys_DicType。

 

　　這樣的一個操做日誌比較籠統，不是能具體到具體的字段值更新，若是要具體到某個具體值的更新，則須要設計新的數據庫。

　　通常狀況下須要這樣幾個表，系統中可能已經有了，可是咱們拿到咱們本身的數據庫中來，一個是數據庫列表的表（就是數據庫中有幾個表）（編號，建立時間，建立人，修改時間，修改人，表名，註釋，是否刪除），而後就是數據庫表下面的字段類型（編號，建立時間，建立人，修改時間，修改人，字段名，字段類型，字段精度，字段說明，字段註釋，表的編號），也就是字段列表，這時的日誌操做表能夠這樣設計(編號，表名，被修改的字段名，修改前值，修改後值，操做人，操做時間，相關模塊，操做IP）這種能記錄修改記錄，可是添加和刪除時記錄就不是很方便控制了。

 

　　還有一個就是數據字典表，我看過不少的數據庫設計，類型表一個接一個，沒有放在一塊兒，還有的乾脆寫在註釋裏，有的根本就沒有，這樣某個程序員走了，這個字段就沒人知道了，即便沒走，本身也有可能時間長了忘掉，因此，見一個基礎數據字典表的做用很是重要，其餘的好比地區表(Sys_DicArea)，漢語拼音表（Sys_DicCharacter）(用來漢字和拼音的轉換)由於數據量較大，單獨建表。這裏介紹通用的數據字典表。

 

 

　　最後補充一些內容，通常設計數據庫是這個樣子的，可是不排除有些特殊的情形，爲了數據的保密性，數據庫的表名和字段名都是一些看似毫無心義的字符數字，好比Table1，Col1，可是有一個表是說明表，或者有對應的數據庫文檔設計。

　　補充：一些列說明了單位類型，能夠在設計數據庫的時候代表，好比HeightIncm,WeightInKg.這樣一目瞭然。

　　防止數據庫設計打補丁的方法是「三少原則」

　　(1)一個數據庫中表的個數越少越好。只有表的個數少了，才能說明系統的E--R圖少而精，去掉了重複的多餘的實體，造成了對客觀世界的高度抽象，進行了系統的數據集成，防止了打補丁式的設計；

　　(2)一個表中組合主鍵的字段個數越少越好。由於主鍵的做用，一是建主鍵索引，二是作爲子表的外鍵，因此組合主鍵的字段個數少了，不只節省了運行時間，並且節省了索引存儲空間；

　　(3)一個表中的字段個數越少越好。只有字段的個數少了，才能說明在系統中不存在數據重複，且不多有數據冗餘，更重要的是督促讀者學會「列變行」，這樣就防止了將子表中的字段拉入到主表中去，在主表中留下許多空餘的字段。所謂「列變行」，就是將主表中的一部份內容拉出去，另外單獨建一個子表。這個方法很簡單，有的人就是不習慣、不採納、不執行。

　　數據庫設計的實用原則是：在數據冗餘和處理速度之間找到合適的平衡點。「三少」是一個總體概念，綜合觀點，不能孤立某一個原則。該原則是相對的，不是絕對的。「三多」原則確定是錯誤的。試想：若覆蓋系統一樣的功能，一百個實體(共一千個屬性)的E--R圖，確定比二百個實體(共二千個屬性)的E--R圖，要好得多。

　　提倡「三少」原則，是叫讀者學會利用數據庫設計技術進行系統的數據集成。數據集成的步驟是將文件系統集成爲應用數據庫，將應用數據庫集成爲主題數據庫，將主題數據庫集成爲全局綜合數據庫。集成的程度越高，數據共享性就越強，信息孤島現象就越少，整個企業信息系統的全局E—R圖中實體的個數、主鍵的個數、屬性的個數就會越少。

　　提倡「三少」原則的目的，是防止讀者利用打補丁技術，不斷地對數據庫進行增刪改，使企業數據庫變成了隨意設計數據庫表的「垃圾堆」，或數據庫表的「大雜院」，最後形成數據庫中的基本表、代碼表、中間表、臨時表雜亂無章，不可勝數，致使企事業單位的信息系統沒法維護而癱瘓。

　　「三多」原則任何人均可以作到，該原則是「打補丁方法」設計數據庫的歪理學說。「三少」原則是少而精的原則，它要求有較高的數據庫設計技巧與藝術，不是任何人都能作到的，由於該原則是杜絕用「打補丁方法」設計數據庫的理論依據。

　　在給定的系統硬件和系統軟件條件下，提升數據庫系統的運行效率的辦法是：

　　(1)在數據庫物理設計時，下降範式，增長冗餘,少用觸發器,多用存儲過程。

　　(2)當計算很是複雜、並且記錄條數很是巨大時(例如一千萬條)，複雜計算要先在數據庫外面，以文件系統方式用C++語言計算處理完成以後，最後才入庫追加到表中去。這是電信計費系統設計的經驗。

　　(3)發現某個表的記錄太多，例如超過一千萬條，則要對該表進行水平分割。水平分割的作法是，以該表主鍵PK的某個值爲界線，將該表的記錄水平分割爲兩個表。若發現某個表的字段太多，例如超過八十個，則垂直分割該表，將原來的一個表分解爲兩個表。

　　(4)對數據庫管理系統DBMS進行系統優化，即優化各類系統參數，如緩衝區個數。

　　(5)在使用面向數據的SQL語言進行程序設計時，儘可能採起優化算法。總之，要提升數據庫的運行效率，必須從數據庫系統級優化、數據庫設計級優化、程序實現級優化，這三個層次上同時下功夫。

　　主鍵設計：

　　一、不建議用多個字段作主鍵，單個表還能夠，可是關聯關係就會有問題，主鍵自增是高性能的。導入導出就有問題。

　　二、通常狀況下，若是有兩個外鍵，不建議採用兩個外鍵做爲聯合住建，另建一個字段做爲主鍵。除非這條記錄沒有邏輯刪除標誌，且該表永遠只有一條此聯合主鍵的記錄。

　　三、通常而言，一個實體不能既無主鍵又無外鍵。在E—R圖中,處於葉子部位的實體,能夠定義主鍵，也能夠不定義主鍵(由於它無子孫),但必需要有外鍵(由於它有父親)。

　　主鍵與外鍵的設計，在全局數據庫的設計中，佔有重要地位。當全局數據庫的設計完成之後，有個美國數據庫設計專家說：「鍵，處處都是鍵，除了鍵以外，什麼也沒有」，這就是他的數據庫設計經驗之談，也反映了他對信息系統核心(數據模型)的高度抽象思想。由於：主鍵是實體的高度抽象，主鍵與、外鍵的配對，表示實體之間的鏈接。

數據庫三範式：

概念的單一化，即一個關係表示一個實體。有點Java面對對象的意思。

一範式就是屬性不可分割。屬性是什麼？就是表中的字段。
不可分割的意思就按字面理解就是最小單位，不能再分紅更小單位了。
這個字段只能是一個值，不能被拆分紅多個字段，不然的話，它就是可分割的，就不符合一範式。
不過能不能分割並無絕對的答案，看需求，也就是看你的設計目標而定。
舉例：
學生信息組成學生信息表，有姓名、年齡、性別、學號等信息組成。
姓名不可拆分吧？因此能夠做爲該表的一個字段。
但我要說這個表要在國外使用呢？人家姓和名要分開，都有特別的意義，因此姓名字段是可拆分的，分爲姓字段和名字段。
簡單來講，一範式是關係數據庫的基礎，但字段是否真的不可拆分，根據你的設計目標而定。

二範式就是要有主鍵，要求其餘字段都依賴於主鍵。
爲何要有主鍵？沒有主鍵就沒有惟一性，沒有惟一性在集合中就定位不到這行記錄，因此要主鍵。
其餘字段爲何要依賴於主鍵？由於不依賴於主鍵，就找不到他們。更重要的是，其餘字段組成的這行記錄和主鍵表示的是同一個東西，而主鍵是惟一的，它們只須要依賴於主鍵，也就成了惟一的。
若是有同窗不理解依賴這個詞，能夠勉強用「相關」這個詞代替，也就是說其餘字段必須和它們的主鍵相關。由於不相關的東西不該該放在一行記錄裏。
舉例：
學生信息組成學生表，姓名能夠作主鍵麼？
不能！由於同名的話，就不惟一了，因此須要學號這樣的惟一編碼才行。
那麼其餘字段依賴於主鍵是什麼意思？
就是「張三」同窗的年齡和性別等字段，不能存儲別人的年齡性別，必須是他本身的，由於張三的學號信息就決定了，這行記錄歸張三全部，不能給無關人員使用。

三範式就是要消除傳遞依賴，方便理解，能夠看作是「消除冗餘」。
消除冗餘應該比較好理解一些，就是各類信息只在一個地方存儲，不出如今多張表中。
好比說大學分了不少系（中文系、英語系、計算機系……），這個系別管理表信息有如下字段組成：
系編號，系主任，系簡介，系架構。
那麼再回到學生信息表，張三同窗的年齡、性別、學號都有了，我能不能把他的系編號，系主任、系簡介也一塊兒存着？
若是你問三範式，固然不行，由於三範式不一樣意。
由於系編號，系主任、系簡介已經存在系別管理表中，你再存入學生信息表，就是冗餘了。
三範式中說的傳遞依賴，就出現了。
這個時候學生信息表中，系主任信息是否是依賴於系編號了？而這個表的主鍵但是學號啊！
因此按照三範式，處理這個問題的時候，學生表就只能增長一個系編號字段。
這樣既能根據系編號找到系別信息，又避免了冗餘存儲的問題。

所謂的範式，是用來學習參考的，設計的時候根據狀況，未必必定要遵照，切記。

總結： 1NF： 字段是最小的的單元不可再分 2NF：知足1NF,表中的字段必須徹底依賴於所有主鍵而非部分主鍵 (通常咱們都會作到) 3NF：知足2NF,非主鍵外的全部字段必須互不依賴 ？？4NF：知足3NF,消除表中的多值依賴