SQL設計規範

MYSQL數據庫設計規範
 
    一、數據庫命名規範
        採用26個英文字母(區分大小寫)和0-9的天然數(常常不須要)加上下劃線'_'組成;
        命名簡潔明確(長度不能超過30個字符);
        例如：user, stat, log, 也能夠wifi_user, wifi_stat, wifi_log給數據庫加個前綴;
        除非是備份數據庫能夠加0-9的天然數：user_db_20151210;
         
    二、數據庫表名命名規範
        採用26個英文字母(區分大小寫)和0-9的天然數(常常不須要)加上下劃線'_'組成;
        命名簡潔明確,多個單詞用下劃線'_'分隔;
        例如：user_login, user_profile, user_detail, user_role, user_role_relation,
            user_role_right, user_role_right_relation
        表前綴'user_'能夠有效的把相同關係的表顯示在一塊兒;
         
    三、數據庫表字段名命名規範
        採用26個英文字母(區分大小寫)和0-9的天然數(常常不須要)加上下劃線'_'組成;
        命名簡潔明確,多個單詞用下劃線'_'分隔;
        例如：user_login表字段 user_id, user_name, pass_word, eamil, tickit, status, mobile, add_time;
        每一個表中必須有自增主鍵,add_time(默認系統時間)
        表與表之間的相關聯字段名稱要求儘量的相同;
     
    四、數據庫表字段類型規範
        用盡可能少的存儲空間來存數一個字段的數據;
        例如：能使用int就不要使用varchar、char,能用varchar(16)就不要使用varchar(256);
        IP地址最好使用int類型;
        固定長度的類型最好使用char,例如：郵編;
        能使用tinyint就不要使用smallint,int;
        最好給每一個字段一個默認值,最好不能爲null;
     
    五、數據庫表索引規範
        命名簡潔明確,例如：user_login表user_name字段的索引應爲user_name_index惟一索引;
        爲每一個表建立一個主鍵索引;
        爲每一個表建立合理的索引;
        創建複合索引請慎重;
         
    六、簡單熟悉數據庫範式
        第一範式(1NF)：字段值具備原子性,不能再分(全部關係型數據庫系統都知足第一範式);
            例如：姓名字段,其中姓和名是一個總體,若是區分姓和名那麼必須設立兩個獨立字段;
         
        第二範式(2NF)：一個表必須有主鍵,即每行數據都能被惟一的區分;
            備註：必須先知足第一範式;
         
        第三範式(3NF)：一個表中不能包涵其餘相關表中非關鍵字段的信息,即數據表不能有沉餘字段;
            備註：必須先知足第二範式;
         
        備註：每每咱們在設計表中不能遵照第三範式,由於合理的沉餘字段將會給咱們減小join的查詢;
              例如：相冊表中會添加圖片的點擊數字段,在相冊圖片表中也會添加圖片的點擊數字段;
               
 
     
MYSQL數據庫設計原則
 
    一、核心原則
        不在數據庫作運算;
        cpu計算務必移至業務層;
        控制列數量(字段少而精,字段數建議在20之內);
        平衡範式與冗餘(效率優先；每每犧牲範式)
        拒絕3B(拒絕大sql語句：big sql、拒絕大事物：big transaction、拒絕大批量：big batch);
 
    二、字段類原則
        用好數值類型(用合適的字段類型節約空間);
        字符轉化爲數字(能轉化的最好轉化,一樣節約空間、提升查詢性能);
        避免使用NULL字段(NULL字段很難查詢優化、NULL字段的索引須要額外空間、NULL字段的複合索引無效);
        少用text類型(儘可能使用varchar代替text字段);
     
    三、索引類原則
        合理使用索引(改善查詢,減慢更新,索引必定不是越多越好);
        字符字段必須建前綴索引;
        不在索引作列運算;
        innodb主鍵推薦使用自增列(主鍵創建聚簇索引,主鍵不該該被修改,字符串不該該作主鍵)(理解Innodb的索引保存結構就知道了);
        不用外鍵(由程序保證約束);
     
    四、sql類原則
        sql語句儘量簡單(一條sql只能在一個cpu運算,大語句拆小語句,減小鎖時間,一條大sql能夠堵死整個庫);
        簡單的事務;
        避免使用trig/func(觸發器、函數不用客戶端程序取而代之);
        不用select *(消耗cpu,io,內存,帶寬,這種程序不具備擴展性);
        OR改寫爲IN(or的效率是n級別);
        OR改寫爲UNION(mysql的索引合併很弱智);
            select id from t where phone = ’159′ or name = ‘john’;
            =>
            select id from t where phone=’159′
            union
            select id from t where name=’jonh’
        避免負向%;
        慎用count(*);
        limit高效分頁(limit越大，效率越低);
        使用union all替代union(union有去重開銷);
        少用鏈接join;
        使用group by;
        請使用同類型比較;
        打散批量更新;
         
    五、性能分析工具
        show profile;
        mysqlsla;
        mysqldumpslow;
        explain;
        show slow log;
        show processlist;

數據庫的設計原則

1. 原始單據與實體之間的關係 
　　能夠是一對1、一對多、多對多的關係。在通常狀況下，它們是一對一的關係：即一張原始單據對應且只對應一個實體。 
在特殊狀況下，它們多是一對多或多對一的關係，即一張原始單證對應多個實體，或多張原始單證對應一個實體。 
這裏的實體能夠理解爲基本表。明確這種對應關係後，對咱們設計錄入界面大有好處。 

　　〖例1〗：一份員工履歷資料，在人力資源信息系統中，就對應三個基本表：員工基本狀況表、社會關係表、工做簡歷表。 
　　　　　　  這就是「一張原始單證對應多個實體」的典型例子。 

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

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

3. 基本表的性質 
　　基本表與中間表、臨時表不一樣，由於它具備以下四個特性： 
　　 (1) 原子性。基本表中的字段是不可再分解的。 
　　 (2) 原始性。基本表中的記錄是原始數據（基礎數據）的記錄。 
　　 (3) 演繹性。由基本表與代碼表中的數據，能夠派生出全部的輸出數據。 
　　 (4) 穩定性。基本表的結構是相對穩定的，表中的記錄是要長期保存的。 
　　理解基本表的性質後，在設計數據庫時，就能將基本表與中間表、臨時表區分開來。 

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

　　〖例2〗：有一張存放商品的基本表，如表1所示。「金額」這個字段的存在，代表該表的設計不知足第三範式， 
　　由於「金額」能夠由「單價」乘以「數量」獲得，說明「金額」是冗餘字段。可是，增長「金額」這個冗餘字段， 
　　能夠提升查詢統計的速度，這就是以空間換時間的做法。 
　　在Rose 2002中，規定列有兩種類型：數據列和計算列。「金額」這樣的列被稱爲「計算列」，而「單價」和 
　　「數量」這樣的列被稱爲「數據列」。 

　　表1 商品表的表結構 
　　商品名稱 商品型號 單價 數量 金額 
　　電視機 29吋 2,500 40 100,000 
　　 
5. 通俗地理解三個範式 
　　通俗地理解三個範式，對於數據庫設計大有好處。在數據庫設計中，爲了更好地應用三個範式，就必須通俗地理解 
　　三個範式(通俗地理解是夠用的理解，並非最科學最準確的理解)： 
　　第一範式：1NF是對屬性的原子性約束，要求屬性具備原子性，不可再分解； 
　　第二範式：2NF是對記錄的唯一性約束，要求記錄有唯一標識，即實體的唯一性； 
　　第三範式：3NF是對字段冗餘性的約束，即任何字段不能由其餘字段派生出來，它要求字段沒有冗餘。 

　　沒有冗餘的數據庫設計能夠作到。可是，沒有冗餘的數據庫未必是最好的數據庫，有時爲了提升運行效率，就必須降 
　　低範式標準，適當保留冗餘數據。具體作法是：在概念數據模型設計時遵照第三範式，下降範式標準的工做放到物理 
　　數據模型設計時考慮。下降範式就是增長字段，容許冗餘。 

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

　　〖例3〗：在「圖書館信息系統」中，「圖書」是一個實體，「讀者」也是一個實體。這兩個實體之間的關係，是一 
　　個典型的多對多關係：一本圖書在不一樣時間能夠被多個讀者借閱，一個讀者又能夠借多本圖書。爲此，要在兩者之 
　　間增長第三個實體，該實體取名爲「借還書」，它的屬性爲：借還時間、借還標誌(0表示借書，1表示還書)，另外， 
　　它還應該有兩個外鍵(「圖書」的主鍵，「讀者」的主鍵)，使它能與「圖書」和「讀者」鏈接。 

注視：

圖書  1 和 該實體取名爲「借還書」 n 
讀者  1 和 該實體取名爲「借還書」 n 

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

8. 正確認識數據冗餘 
　　主鍵與外鍵在多表中的重複出現, 不屬於數據冗餘，這個概念必須清楚，事實上有許多人還不清楚。非鍵字段的重 
　　復出現, 纔是數據冗餘！並且是一種低級冗餘，即重複性的冗餘。高級冗餘不是字段的重複出現，而是字段的派生出現。 

　　〖例4〗：商品中的「單價、數量、金額」三個字段，「金額」就是由「單價」乘以「數量」派生出來的，它就是冗餘， 
　　並且是一種高級冗餘。冗餘的目的是爲了提升處理速度。只有低級冗餘纔會增長數據的不一致性，由於同一數據，可 
　　能從不一樣時間、地點、角色上屢次錄入。所以，咱們提倡高級冗餘(派生性冗餘)，反對低級冗餘(重複性冗餘)。 

9. E--R圖沒有標準答案 
　　信息系統的E--R圖沒有標準答案，由於它的設計與畫法不是唯一的，只要它覆蓋了系統需求的業務範圍和功能內容， 
　　就是可行的。反之要修改E--R圖。儘管它沒有唯一的標準答案，並不意味着能夠隨意設計。好的E—R圖的標準是： 
　　結構清晰、關聯簡潔、實體個數適中、屬性分配合理、沒有低級冗餘。 

10 . 視圖技術在數據庫設計中頗有用 
　　與基本表、代碼表、中間表不一樣，視圖是一種虛表，它依賴數據源的實表而存在。視圖是供程序員使用數據庫的 
　　一個窗口，是基表數據綜合的一種形式, 是數據處理的一種方法，是用戶數據保密的一種手段。爲了進行復雜處理、 
　　提升運算速度和節省存儲空間, 視圖的定義深度通常不得超過三層。 若三層視圖仍不夠用, 則應在視圖上定義臨時表, 
　　 在臨時表上再定義視圖。這樣反覆交迭定義, 視圖的深度就不受限制了。 

　　對於某些與國家政治、經濟、技術、軍事和安全利益有關的信息系統，視圖的做用更加劇要。這些系統的基本表完 
　　成物理設計以後，當即在基本表上創建第一層視圖，這層視圖的個數和結構，與基本表的個數和結構是徹底相同。 
　　而且規定，全部的程序員，一概只准在視圖上操做。只有數據庫管理員，帶着多我的員共同掌握的「安全鑰匙」， 
　　才能直接在基本表上操做。請讀者想一想：這是爲何？ 

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

12. 完整性約束表如今三個方面 
　　域的完整性：用Check來實現約束，在數據庫設計工具中，對字段的取值範圍進行定義時，有一個Check按鈕，通 
　　過它定義字段的值城。 
　　參照完整性：用PK、FK、表級觸發器來實現。 
　　用戶定義完整性：它是一些業務規則，用存儲過程和觸發器來實現。 

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

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

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

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

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

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

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

14. 提升數據庫運行效率的辦法 
　　在給定的系統硬件和系統軟件條件下，提升數據庫系統的運行效率的辦法是： 
　　 (1) 在數據庫物理設計時，下降範式，增長冗餘, 少用觸發器, 多用存儲過程。 
　　 (2) 當計算很是複雜、並且記錄條數很是巨大時(例如一千萬條)，複雜計算要先在數據庫外面，以文件系統方 
　　　　式用C++語言計算處理完成以後，最後才入庫追加到表中去。這是電信計費系統設計的經驗。 
　　 (3) 發現某個表的記錄太多，例如超過一千萬條，則要對該表進行水平分割。水平分割的作法是，以該表主鍵 
　　　　PK的某個值爲界線，將該表的記錄水平分割爲兩個表（便可以表維護 錶行數過大 手動分割爲兩個  建個兩表union的視圖對程序透明）。若發現某個表的字段太多，例如超過八十個，則 
　　　　垂直分割該表，將原來的一個表分解爲兩個表。 
　　 (4) 對數據庫管理系統DBMS進行系統優化，即優化各類系統參數，如緩衝區個數。 
　　 (5) 在使用面向數據的SQL語言進行程序設計時，儘可能採起優化算法。 
　　　　總之，要提升數據庫的運行效率，必須從數據庫系統級優化、數據庫設計級優化、程序實現級優化，這三 
　　　　個層次上同時下功夫。 

　　上述十四個技巧，是許多人在大量的數據庫分析與設計實踐中，逐步總結出來的。對於這些經驗的運用，讀者不能生幫硬套，死記硬背，而要消化理解，實事求是，靈活掌握。並逐步作到：在應用中發展，在發展中應用。

轉載自：http://www.javaeye.com/topic/281611

=================================

denormalization在DATABASE裏怎麼解釋？給個例子
2008-04-01 21:16
辭典:反向規格化, 阻礙正常化
就是咱們一般所說的逆規範化.
好比在一個表裏設置兩個主鍵.
好比在兩個表之間的關係爲多對多關係.
等等都是違反標準範式的
不管是規範化仍是逆規範化都是爲了提升數據庫性能.
初學者仍是儘可能作到規範化的好.