• 數據庫開發規范

  1. 數據庫命名規范

  前綴

  • 對象前綴命名: 前綴命名一般用小寫
  • 表的前綴: 業務模塊組名前綴
  • 存儲過程前綴: udp ，系統存儲過程（sp）
  • 自定義函數前綴: udf(User define function)
  • 視圖前綴: udv(User Define View)表示用戶自定義視圖
  • 自定義約束前綴: uck(User Checker)用戶自定義約束
  • 索引前綴: idx(Index)表示索引
  • 主鍵前綴: pk(primary keys)表示主鍵
  • 主鍵前綴: fk(foreign keys)表示主鍵

  常見命名約定

  • 表名使用單數名
    例如：對存儲客人信息的表（Customer）不使用Customers

  • 字段名不要存在無用前綴
    例如表‘WeiXinConfig’，既然我已經知道這張表是關于微信的表，里面的名稱字段可以可以使用Name,不需要添加無用的前綴類似‘WeiXinName’，‘WeiXinGuanZhuMsg’，‘WeiXinUpImgMsg’等

  • 避免無謂的表名后綴

    • 表是用來存儲數據信息的,表是行的集合。那么如果表名已經能夠很好地說明其包含的數據信 息，就不需要再添加體現上面兩點的后綴了。
    • GuestInfo(存儲客戶信息)應寫成Guest，FlightList（存儲航班信息的表）應寫成Flight

  • 所有表示時間的字段，統一以 Date 來作為結尾（而不是有的使用Date,有的使用Time）

    以大家都熟悉的論壇來說，需要記錄會員最后一次登錄的時間，這時候一般人都會把這個字段命名為LoginTime 或者 LoginDate。這時候，已經產生了一個歧義;如果僅看表的字段名稱，不去看表的內容，很容易將LoginTime理解成登錄的次數，因為，Time還有一個很常用的意思，就是次數

  • 所有表示數目的字段，都應該以Count作為結尾

  • 所有代表鏈接的字段，均為Url結尾

  • 所有名稱的字符范圍為：A-Z, a-z, 0-9 和_(下劃線)。不允許使用其他字符作為名稱

  • 采用英文單詞或英文短語（包括縮寫）作為名稱，不能使用無意義的字符或漢語拼音

  • 名稱應該清晰明了，能夠準確表達事物的含義，最好可讀，遵循“見名知意”的原則

  • 字段名不能使用保留關鍵字

  2. 數據庫設計規范

  范式設計與反范式設計

  • 關于范式 Normal Form

    范式是關系數據庫理論的基礎，也是我們在設計數據庫結構過程中所要遵循的規則和指導方法。數據庫的設計范式是數據庫設計所需要滿足的規范。只有理解數據庫的設計范式，才能設計出高效率、優雅的數據庫，否則可能會設計出錯誤的數據庫。
    目前關系數據庫有六種范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，還又稱完美范式）。滿足最低要求的叫第一范式，簡稱1NF。在第一范式基礎上進一步滿足一些要求的為第二范式，簡稱2NF。其余依此類推。各種范式呈遞次規范，越高的范式數據庫冗余越小。通常所用到的只是前三個范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。

    • 第一范式（1NF）： 強調的是列的原子性，即列不能夠再分成其他幾列。簡而言之，第一范式就是無重復的列。
    • 第二范式（2NF）： 首先要滿足它是1NF，另外還需要包含兩部分內容：一是表必須有一個主鍵；二是沒有包含在主鍵中的列必須完全依賴于主鍵，而不能只依賴于主鍵的一部分。
    • 第三范式（3NF） 在1NF基礎上，任何非主屬性不依賴于其它非主屬性[在2NF基礎上消除傳遞依賴]。第三范式（3NF）是第二范式（2NF）的一個子集，即滿足第三范式（3NF）必須滿足第二范式（2NF）。

  • 關于范式的討論

    • 第二范式和第三范式如何區別？

      第二范式：非主鍵列是否依賴主鍵（包括一列通過某一列間接依賴主鍵），要是有依賴關系的就是第二范式；</br>
      第三范式：非主鍵列是否是直接依賴主鍵，不能是那種通過傳遞關系的依賴的。要是符合這種就是第三范式

    • 使用范式有哪些優點和缺點？

      范式可以避免數據冗余，減少數據庫的空間，減輕維護數據完整性的麻煩。
      范式再給我們帶來的上面的好處時，同時也伴隨著一些不好的地方：按照范式的規范設計出來的表，等級越高的范式設計出來的表越多。
      
      如第一范式可能設計出來的表可能只有一張表而已，再按照第二范式去設計這張表時就可能出來兩張或更多張表，如果再按第三范式或更高的范式去設計這張表會出現更多比第二范式多的表。表的數量越多，當我們去查詢一些數據，必然要去多表中去查詢數據，這樣查詢的時間要比在一張表中查詢中所用的時間要高很多。也就是說我們所用的范式越高，對數據操作的性能越低。所以我們在利用范式設計表的時候，要根據具體的需求再去權衡是否使用更高范式去設計表。在一般的項目中，我們用的最多也就是第三范式，第三范式也就可以滿足我們的項目需求，性能好而且方便管理數據；當我們的業務所涉及的表非常多，經常會有多表發生關系，并且我們對表的操作要時間上要盡量的快，這時可以考慮我們使用“反范式”。

  • 關于反范式

    不滿足范式的模型，就是反范式模型
    反范式跟范式所要求的正好相反，在反范式的設計模式，我們可以允許適當的數據的冗余，用這個冗余去取操作數據時間的縮短。本質上就是用空間來換取時間，把數據冗余在多個表中，當查詢時可以減少或者是避免表之間的關聯；
    

  • 范式和反范式的對比

    模型	優點	缺點
    范式化模型	數據無冗余，便于更新	不利于查詢操作
    反范式化模型	便于查詢	數據冗余，不利于更新

  RDBMS模型設計過程中，常常使用范式約束我們的模型，但在NOSQL模型中則大量采用反范式，在設計的時候 結合讀寫的業務場景類分析 對比各項指標 進行綜合考慮實施。

主鍵設計原則

• 主鍵的數據類型

  最常見的主鍵數據類型是數字類型、固定長度的字符類型和GUID類型。通常情況下，RDBMS會在主鍵上建立聚集索引（SQL Server默認都這么做），由于我們使用B-Tree的數據結構來存儲索引數據，所以一般對主鍵有以下兩個要求：

  • 越短越好——越短在一個Page中存儲的節點越多，檢索速度就越快。
  • 順序增長——如果每一條插入的數據的主鍵都比前面的主鍵大，那么B-Tree上的節點也是順序增長的，不會造成頻繁的B-Tree分割。

  越短越好是為了查詢的速度快，順序增長是為了插入速度快。

  有了這兩個要求，我們再來分析下各個數據類型：

  • 數字類型：根據數據量決定是用Int16還是Int32或者Int64，能用Int32的就不需要使用Int64。
  • 字符類型：基本不滿足前面提到的2點要求，字符類型一般不會很短，而且也很可能不是順序增長的，所以不是特別推薦的主鍵類型。當然如果確實業務需求使用字符類型，那么也盡量使用char(XX)而不要使用varchar(XX)，因為在RDBMS中，對于定長字符串和變成字符串的數據結構和處理是不一樣的，varchar的性能更差。
  • GUID類型：這個類型并不是所有數據庫都有對應的數據類型，SQL Server有uniqueidentifier，MySQL沒有。GUID類型在SQL Server中是16個字節，不算短，比4個字節的Int32長多了。在插入新數據時，GUID一般都是使用NewId()這樣的生成隨機GUID的方式生成的，所以也不是順序增長的，在插入速度上不會很快。
    通過上面的比較，我們知道使用數字類型是更好的方式，那么我們為什么還會有人使用GUID和字符串來當主鍵呢？那是因為：

  相對于數字類型，字符類型更易讀易記，在檢索關聯的數據時，更方便直接。

  GUID的優勢是全球唯一，也就是說同樣的系統，如果部署了多套環境，那么里面的數據的主鍵仍然是唯一的，這樣有助于數據的集成。典型的例子就是一個系統在全國每個省份都部署一套，每個省份的數據各種錄入，互不干擾，然后再把每個省的數據集成起來為總部做分析。

  • 數據庫主鍵與業務主鍵

  前面說到一個表可能有很多個唯一標識的候選鍵，那么這么多候選鍵中，哪個應該拿來做主鍵呢？一種方案是再新建一個獨立的字段作為主鍵，該字段并沒有業務含義，只是一個自增列或者流水號，用于唯一標識每一行數據，這是數據庫主鍵。另外一種方案是選擇其中較短較常用的屬性作為主鍵，這是業務主鍵。個人建議是不要使用任何有業務含義的字段作主鍵，而是使用一個自增的（或者系統生成的）沒有實際業務意義的字段作為主鍵。為什么呢？主要是出于以下考慮：

  具有業務意義的字段很可能是用戶從系統錄入的，不要信任用戶的任何輸入，只要是用戶自己錄入的，那么就很有可能錄錯了，如果發現錄入錯誤，這個時候再對主鍵進行修改，將會涉及到大量關聯的外鍵表的修改，是很麻煩的一件事情。比如在做人員表的時候，就不要使用員工號或者身份證號做主鍵。

  具有業務意義的字段雖然在當前階段是唯一的，是不變的，但是并不能保證隨著公司政策變動、業務調整等原因，導致該業務字段需要修改，以滿足新的業務要求，這個時候要修改主鍵也是很麻煩的事情。比如部門表，我們以部門Code作為主鍵，但是后來部門變動，Code修改，則系統部門表的主鍵也得更改。

  還有一個原因是業務主鍵在數據錄入的時候不一定是明確知道的，有時我們會在不知道業務主鍵的情況下，就錄入其他相關信息，這個時候，如果使用業務主鍵做數據庫的主鍵，那么數據將無法錄入。比如員工表把員工號作為主鍵，那么員工還沒有入職，沒有員工號的時候，HR需要先維護一些該預入職員工的信息是不可能的。

  • 聯合主鍵

  聯合主鍵就是以多個字段來唯一標識每一行數據。前面已經說到主鍵應該越短越好，而且是建議是一個沒有意義的自增列，那么是不是就不會再需要聯合主鍵呢？答案是否定的，我們仍然可能會使用到聯合主鍵。聯合主鍵主要使用在多對多的關系時，中間表就需要使用聯合主鍵。在簡單的多對多關系中，我們不需要為中間的關聯建立實體，所以中間表可能就只需要兩列，分別是兩個實體表的主鍵。

• 主鍵值的生成

  主鍵值的生成 主要有這么幾種生成方式：

  • 自增，這是SQL Server常用的主鍵生成方式，完全由數據庫管理主鍵的值。
  • Sequence對象，這是Oracle常用的主鍵生成方式，現在SQL Server已支持。主要是在數據庫中有一個Sequence對象，通過該對象生成主鍵。
  • GUID，這是用于GUID類型的主鍵，可以使用newid()這種數據庫提供的函數，或者使用程序生成Guid并賦值。
  • 其他程序賦值，完全由程序根據自己的算法生成并賦值。
  • 主鍵與索引

  在概念和作用上，主鍵與索引是完全兩個不同的東西，但是由于我們大部分情況下都是使用主鍵檢索數據，所以大部分數據庫的默認實現，在建立主鍵時會自動建立對應的索引。

  以SQL Server為例，默認情況下，建立主鍵的列，就會建立聚集索引，但是實際上，我們可以在建立主鍵時不使用聚集索引。另外還有一個唯一約束（索引）的概念，該索引中的數據必須是唯一不能重復的，感覺和主鍵的意義一樣，但是還是有一點點區別。

  主鍵是只能由一個，而唯一約束（索引）在一個表中可以有多個。

  主鍵不能為空，而唯一約束（索引）是可以為空的。

外鍵設計原則

>數據庫外鍵的主要作用是 保持數據的一致性 完整性，但對于外鍵的使用主要一直是矛盾的焦點，主要有兩個問題：一個是如何保證數據庫數據的完整性和一致性；二是數據庫性能問題

• 觀點一
  • 由數據庫自身保證數據一致性，完整性，更可靠，因為程序很難100％保證數據的完整性，而用外鍵即使在數據庫服務器當機或者出現其他問題的時候，也能夠最大限度的保證數據的一致性和完整性。
  • 有主外鍵的數據庫設計可以增加ER圖的可讀性，這點在數據庫設計時非常重要。
  • 外鍵在一定程度上說明的業務邏輯，會使設計周到具體全面。
• 觀點二
  • 可以用應用程序保證數據的完整性
  • 過分強調或者說使用主鍵／外鍵會平添開發難度，導致表過多等問題
  • 不用外鍵時數據管理簡單，操作方便，性能高
• 總結:
  • 在大型系統中（性能要求不高，安全要求高），使用外鍵；在大型系統中（性能要求高，安全自己控制），不用外鍵；小系統隨便，最好用外鍵。
  • 用外鍵要適當，不能過分追求
  • 不用外鍵而用程序控制數據一致性和完整性時，應該寫一層來保證，然后個個應用通過這個層來訪問數據庫。

索引設計原則

>  基于合理的數據庫設計，經過深思熟慮后為表建立索引，是獲得高性能數據庫系統的基礎。而未經合理分析便添加索引，則會降低系統的總體性能。索引雖然說提高了數據的訪問速度，但同時也增加了插入、更新和刪除操作的處理時間。<br/>
是否要為表增加索引、索引建立在那些字段上，是創建索引前必須要考慮的問題。解決此問題的一個比較好的方法，就是分析應用程序的業務處理、數據使用，為經常被用作查詢條件、或者被要求排序的字段建立索引。基于優化器對SQL語句的優化處理。

我們在創建索引時可以遵循下面的一般性原則：

• (1)為經常出現在關鍵字order by、group by、distinct后面的字段，建立索引。
  在這些字段上建立索引，可以有效地避免排序操作。如果建立的是復合索引，索引的字段順序要和這些關鍵字后面的字段順序一致，否則索引不會被使用。
• （2）在union等集合操作的結果集字段上，建立索引。其建立索引的目的同上。
• （3）為經常用作查詢選擇的字段，建立索引。
• （4）在經常用作表連接的屬性上，建立索引。
• （5）考慮使用索引覆蓋。對數據很少被更新的表，如果用戶經常只查詢其中的幾個字段，可以考慮在這幾個字段上建立索引，從而將表的掃描改變為索引的掃描。

除了以上原則，在創建索引時，我們還應當注意以下的限制：

• （1）限制表上的索引數目。
  對一個存在大量更新操作的表，所建索引的數目一般不要超過3個，最多不要超過5個。索引雖說提高了訪問速度，但太多索引會影響數據的更新操作。
• （2）不要在有大量相同取值的字段上，建立索引。
  在這樣的字段（例如：性別）上建立索引，字段作為選擇條件時將返回大量滿足條件的記錄，優化器不會使用該索引作為訪問路徑。
• （3）避免在取值朝一個方向增長的字段（例如：日期類型的字段）上，建立索引；對復合索引，避免將這種類型的字段放置在最前面。
  由于字段的取值總是朝一個方向增長，新記錄總是存放在索引的最后一個葉頁中，從而不斷地引起該葉頁的訪問競爭、新葉頁的分配、中間分支頁的拆分。此外，如果所建索引是聚集索引，表中數據按照索引的排列順序存放，所有的插入操作都集中在最后一個數據頁上進行，從而引起插入“熱點”。
• （4）對復合索引，按照字段在查詢條件中出現的頻度建立索引。
  在復合索引中，記錄首先按照第一個字段排序。對于在第一個字段上取值相同的記錄，系統再按照第二個字段的取值排序，以此類推。因此只有復合索引的第一個字段出現在查詢條件中，該索引才可能被使用。
  因此將應用頻度高的字段，放置在復合索引的前面，會使系統最大可能地使用此索引，發揮索引的作用。
• （5）刪除不再使用，或者很少被使用的索引。
  表中的數據被大量更新，或者數據的使用方式被改變后，原有的一些索引可能不再被需要。數據庫管理員應當定期找出這些索引，將它們刪除，從而減少索引對更新操作的影響。

SqlServer數據類型

使用原則

• 1.字符類型建議采用varchar/nvarchar數據類型
• 2.金額貨幣建議采用money數據類型
• 3.科學計數建議采用numeric數據類型
• 4.自增長標識建議采用bigint數據類型 (數據量一大，用int類型就裝不下，那以后改造就麻煩了)
• 5.時間類型建議采用為datetime數據類型
• 6.禁止使用text、ntext、image老的數據類型
• 7.禁止使用xml數據類型、varchar(max)、nvarchar(max)

3. 數據庫查詢規范

禁止在數據庫做復雜運算

禁止使用SELECT *

減少內存消耗和網絡帶寬

給查詢優化器有機會從索引讀取所需要的列

表結構變化時容易引起查詢出錯

禁止在索引列上使用函數或計算

禁止在索引列上使用函數或計算

在where子句中,如果索引是函數的一部分,優化器將不再使用索引而使用全表掃描

禁止使用游標

禁止使用觸發器

禁止使用存儲過程

禁止在查詢里指定索引

With(index=XXX)（ 在查詢里我們指定索引一般都用With(index=XXX) ）

隨著數據的變化查詢語句指定的索引性能可能并不最佳

索引對應用應是透明的，如指定的索引被刪除將會導致查詢報錯，不利于排障

新建的索引無法被應用立即使用，必須通過發布代碼才能生效

變量/參數/關聯字段類型必須與字段類型一致

避免類型轉換額外消耗的CPU，引起的大表scan尤為嚴重

參數化查詢

限制JOIN個數

單個SQL語句的表JOIN個數不能超過5個

過多的JOIN個數會導致查詢分析器走錯執行計劃

過多JOIN在編譯執行計劃時消耗很大

限制SQL語句長度及IN子句個數

在 IN 子句中包括數量非常多的值（數以千計）可能會消耗資源并返回錯誤 8623 或 8632，要求IN子句中條件個數限制在100個以內

盡量避免大事務操作

只在數據需要更新時開始事務，減少資源鎖持有時間

增加事務異常捕獲預處理機制

禁止使用數據庫上的分布式事務

除非必要SELECT語句都必須加上NOLOCK

指定允許臟讀。不發布共享鎖來阻止其他事務修改當前事務讀取的數據，其他事務設 置的排他鎖不會阻礙當前事務讀取鎖定數據。允許臟讀可能產生較多的并發操作，但其代價是讀取以后會被其他事務回滾的數據修改。這可能會使您的事務出錯，向用戶顯示從未提交過的數據，或者導致用戶兩次看到記錄（或根本看不到記錄

使用UNION ALL替換UNION

UNION會對SQL結果集去重排序，增加CPU、內存等消耗

查詢大量數據使用分頁或TOP

合理限制記錄返回數，避免IO、網絡帶寬出現瓶頸

遞歸查詢層級限制

使用 MAXRECURSION 來防止不合理的遞歸 CTE 進入無限循環

EXISTS替代IN

盡量避免使用OR運算符

對于OR運算符，通常會使用全表掃描，考慮分解成多個查詢用UNION/UNION ALL來實現，這里要確認查詢能走到索引并返回較少的結果集

增加事務異常處理機制

輸出列使用二段式命名格式

多表查詢 使用別名 查詢結果 別名.字段

4. 數據庫架構

讀寫分離

• 設計之初就考慮讀寫分離，哪怕讀寫同一個庫，有利于快速擴容
• 按照讀特征把讀分為實時讀和可延遲讀分別對應到寫庫和讀庫
• 讀寫分離應該考慮在讀不可用情況下自動切換到寫端

Schema解耦

• 禁止跨庫Join

數據生命周期

• 根據數據的使用頻繁度，對大表定期分庫歸檔
• 主庫/歸檔庫物理分離

日志類型的表應分區或分表

• 對于大的表格要進行分區，分區操作將表和索引分在多個分區，通過分區切換能夠快速實現新舊分區替換，加快數據清理速度，大幅減少IO資源消耗

頻繁寫入的表，需要分區或分表