本文最初發佈於relinx.io博客，經原作者授權由InfoQ中文站翻譯並分享。
爲什麼要關注數據庫設計？
無論是應用程序，還是數據庫如何變化，數據始終是最重要的部分。通常，數據是系統存在的首要目的。這就是爲什麼，我們不應該只把數據庫系統看作是保存數據的黑盒子，而要將其看成驗證和防止數據腐化的工具。
要做到這一點，就要有健壯和深思熟慮的數據庫設計。當然，業務邏輯是在應用層編碼，它確保數據在到達數據庫之前的格式是正確的。
但是，誰能保證網絡故障或缺陷不會放行不可靠的“客人”？此外，應用層並不是通往數據庫的唯一的“門”。我們可以使用導入腳本、維護腳本，DBA和開發人員也會與之交互。我們可以在底層採取預防措施確保在數據存儲前總是進行檢查。
擁有健壯、可靠的數據也有助於開發和測試。將一個列設置爲Not Null可以省掉許多假設該列爲空的測試場景，還能簡化代碼，讓開發人員不用（幾乎）每次訪問它之前都檢查值。
在強調了良好的數據庫設計的重要性後，讓我們看看可以使用哪些工具來實現它。
規範化
這無疑是良好設計的首要原則。這裏，我們不打算深入研究規範化規則，只是想強調它的重要性。
關於這個話題，這裏有份不錯的資料，你可以進一步閱讀。
數據類型
另一件要注意的事情是定義適當的屬性類型。這不僅可以提高數據庫的性能，還能在存儲數據前驗證數據。所以，我們應該在“integer”、“numeric”字段中保存數值數據；在“timestamp”、“timestamptz”字段中保存時間戳；在“bit”、“char(1)”或“boolean”字段中保存布爾值等等。
日期值得特別注意。如果Date屬性假設只有日期部分（OrderDate，ReleaseDate），請使用沒有時間部分的Date類型。如果你只需要保留時間（StartTime，EndTime），就使用合適的時間類型。
如果不需要指定精度，則將其指定爲零（“time(0)”）。對帶有時間部分的日期，有一個問題是，你必須總是截斷時間部分，只顯示日期，並且當你要在與數據庫所在時區不同的地方顯示時，要確保格式化後不會顯示成昨天或明天。當跳轉到夏令時的時候，帶有時間部分的日期時間加減也可能出現問題。
約束
約束是本文討論的重點。它們將無效數據排除在外，並確保數據的健壯性。讓我們一個一個來看。
非空約束
如果業務規則要求該屬性應該始終存在，那麼要毫不猶豫地將其設置爲Not Null。適合設置爲Not Null的字段有Id、Name、AddedDate、IsActive、State、CategoryId（如果所有項都應該有一個類別）、ItemCount、Price以及許多其他字段。通常，這些屬性在業務邏輯中扮演重要角色。其他可選的信息字段可能還是可以設置爲Null。
但是要注意，不要對可以爲空的屬性使用Not Null約束。例如，一個長時間運行的任務總有一個StartTimestamp（Not Null），但是隻有在任務完成時才更新EndTimestamp（Null）。
另一個典型的例子是，Employee表的ManagerId，並不是所有員工都有經理。不要試圖讓ManagerId不爲空，併爲沒有經理的員工插入“0”或“-1”。當我們添加外鍵約束時，這將導致其他問題。
唯一約束
同樣，根據業務規則，一些屬性（或屬性的組合）應該是惟一的，比如Id、PinNumber、BookId和AuthorId、OrderNo等。應該通過添加惟一約束來保證這些屬性的惟一。
還有一點要注意：可以使用唯一索引來實現同樣的效果，但是添加約束是更好的方法。因爲當添加惟一約束時，會自動創建非惟一索引。
因此，如果出於某種原因，你必須臨時禁用/啓用約束，將會非常容易。在使用唯一索引的情況下，你必須刪除/重新創建索引，從性能和時間方面來說，這是一個昂貴的操作。
主鍵
Not Null和唯一約束一起構成主鍵。當我們想到主鍵時，會很快想到Id或ObjectId之類的列。但是主鍵也可以是複合的，比如BookId和AuthorId。
這裏有個難題是，是使用單獨的Id列作爲主鍵，還是將兩者的組合作爲主鍵？通常，使用單獨的Id列是一種更好的方法，因爲它可以使連接更加清晰，還能方便地將另一列添加到惟一組合中。但是，即使有了一個單獨的主鍵（Id），我們還是要爲BookId和AuthorId列添加唯一約束。
Check約束
Check約束允許我們定義數據的有效值/範圍。適合Check約束的屬性有百分比（0到100之間）、狀態（0、1、2）、價格、金額、總數（大於或等於0）、PinNumber（固定長度）等。
同樣，不要嘗試將業務邏輯編碼到Check約束中。我記得有一次，在AccountBalance列中添加了一個“大於或等於零”的Check約束，從而避免了意外透支。
默認約束
默認約束也很重要。它們允許我們向現有表中添加新的Not Null列，並使“舊”API與新結構兼容，直到所有各方都完成升級（儘管在完全升級後，默認約束應該刪除）。
這裏要記住一點。不要在默認約束中編寫業務邏輯。例如，函數“now()”可能很適合（儘管不總是）作爲日誌表中的時間戳字段的默認值，但不適合Orders表的OrderDate字段。你可能會傾向於在插入語句中省略OrderDate，而依賴於默認約束，但這意味着將業務邏輯擴展到數據庫層。
此外，在某些情況下，業務可能只在訂單批准後纔給OrderDate賦值，因爲默認約束深埋在數據庫中，所以，當我們對應用層的代碼進行更改時，它不會那麼明顯。
外鍵約束
外鍵約束是關係數據庫設計之王。外鍵與主鍵一起確保表之間的數據一致性。規範化規則告訴我們何時將數據提取到表中並使用外鍵引用它。這裏我們將關注細節差別，比如OnDelete和OnUpdate規則。
讓我們從簡單的部分開始：OnUpdate。外鍵引用主鍵，它們很少（如果有的話）被修改。因此，OnUpdate規則不是很常用，但將其設置爲Cascade還是有意義的，因爲我們有時可能必須更新某些行的主鍵（通常在遷移後）。這樣，數據庫將允許我們進行更新，並將新的id傳播到子表中。
OnDelete規則有點複雜。根據數據庫的不同，我們有NoAction、Restrict、SetNull、SetDefault和Cascade選項。那麼，選擇哪一個呢？
通常，對於鍵引用查找或不引用實體的實體，我們選擇NoAction。例如，Products -> Categories、Books -> Authors等。在大多數情況下，Restrict與NoAction是相同的，但是對於某些數據庫，它們有細微的區別。
另一方面，當子記錄不能在沒有父記錄的情況下存在時，選擇Cascade。在Book和Author示例中，當刪除一本書時，我們也應該從BookAuthor表中刪除記錄。其他例子有OrderDetails -> Orders、PostComments -> Posts等。這裏，有些人可能會不同意，數據庫不應該自動刪除子行，它們應該由應用層刪除。根據業務邏輯，是這樣的。但有時“不重要的”子項刪除可以委託給數據庫。
SetNull很少使用。例如，Employee.ManagerId和Employee.Id之間的外鍵可以是SetNull。當一名經理被撤職，他的下屬就沒經理了。顯然，只有當列可爲空時才能選擇該項規則。
在這些規則中，SetDefault最罕見。當父記錄被刪除時，它將列設置爲其默認值。因爲外鍵引用主鍵，我們很難想象一個有外鍵的字段將默認值硬編碼。但無論如何，這個選項是存在的，我們還是有可能需要它。
索引
索引是良好數據庫設計的重要組成部分，但有點偏離我們的討論，因爲它們幾乎不能保護我們的數據（惟一索引除外）。需要注意的一點是：一些RDBMS系統（例如Oracle）會在創建外鍵時自動創建索引，而無需我們操心。其他數據庫（例如MS SQL Server）不會這樣做，我們必須自己添加索引。
小結
一個深思熟慮的設計可以爲我們節省大量的編碼、測試和故障排除時間。在設計良好的數據庫上編寫查詢和報表令人愉快。將數據發佈並遷移到新系統也會非常容易。
編碼快樂！
原文鏈接：