作者：Mokhtar Ebrahim 譯者：姚佳靈

作為數(shù)據(jù)庫設計人員，當我們負責數(shù)據(jù)庫項目時，在數(shù)據(jù)庫設計以及把數(shù)據(jù)庫部署到生產(chǎn)環(huán)境的過程中可能會遇到一些挑戰(zhàn)。

其中一些問題不可避免，也無法控制。但是，其中相當一部分可以追溯到數(shù)據(jù)庫設計本身的質(zhì)量。我們在初步階段所做的決定會對數(shù)據(jù)庫最終的工作情況有深遠的影響。

糟糕的預規(guī)劃

如果我們要建一所房子，我們不會聘請一位工程承包商，然后馬上就要求他們開始打地基。這會導致災難發(fā)生。至少，我們需要就建房計劃和藍圖達成一致。數(shù)據(jù)庫設計也一樣。我們規(guī)劃得越好，設計的輸出質(zhì)量就越高。

好的數(shù)據(jù)庫是深思熟慮的結(jié)果，而不是臨時想法的集合。糟糕的設計規(guī)劃會導致結(jié)構(gòu)性問題，該數(shù)據(jù)庫一旦推出后，要解決這些問題是相當昂貴的。我們不可能總是能預測到數(shù)據(jù)庫會遇到的所有問題，但是好的規(guī)劃確保我們可以把問題減少到只有那些真正無法避免的問題。

未能理解數(shù)據(jù)的用途

創(chuàng)建數(shù)據(jù)庫的目的相當廣泛。從存儲個人私人信息的小型數(shù)據(jù)庫到處理海量信息的大規(guī)模企業(yè)數(shù)據(jù)庫。設計人員必須明白數(shù)據(jù)庫的目的所在，以便用最符合這些目標的方式來設計。

要問的關鍵問題包括：數(shù)據(jù)的性質(zhì)、數(shù)據(jù)獲得的方式、數(shù)據(jù)存儲和檢索的頻率、數(shù)據(jù)的規(guī)模、使用數(shù)據(jù)的應用程序是什么。在工作日結(jié)束時手動輸入數(shù)據(jù)的數(shù)據(jù)庫和實時捕獲并自動存儲數(shù)據(jù)的復雜的行業(yè)數(shù)據(jù)庫不能用同一種設計模型。

設計的關鍵是確保數(shù)據(jù)效率、可用性和安全性的(請參考PostgreSQL 安全)。忽略數(shù)據(jù)的目的將導致設計看上去符合所有的條條框框，但實際上是不健全的。

規(guī)范化不足

數(shù)據(jù)庫設計不是一個嚴格確定的過程。兩個遵循同樣設計規(guī)范的開發(fā)人員最終可以設計出兩個截然不同的數(shù)據(jù)庫。這主要是因為任何軟件工程項目都固有的創(chuàng)造性。盡管如此，設計的一些核心原則對確保數(shù)據(jù)庫以最佳方式運行至關重要。其中之一就是規(guī)范化。規(guī)范化指的是用于把表分解成組成部分的技術。我們執(zhí)行該操作，直到我們讓每一張表只表示一種事物，而列描述該表所代表的項的屬性。規(guī)范化是一種古老的計算概念，已經(jīng)有 30 多年的歷史了。事實上，SQL 主要用于讀取和操作規(guī)范化數(shù)據(jù)集。為了理解規(guī)范化，有必要了解 SQL 的工作原理。

SQL 本質(zhì)上是一種迭加式語言，適用于輕松創(chuàng)建結(jié)果集或值集。使用 FROM 子句，我們可以從一張表中提取數(shù)據(jù)，并使用 JOIN 把數(shù)據(jù)添加到另一張表的內(nèi)容中。我們可以使用幾乎無限數(shù)量的表來生成我們需要的數(shù)據(jù)。SQL 的迭加能力對數(shù)據(jù)庫開發(fā)和性能來說都至關重要。

當索引與鍵值完全同步時，索引效果最佳。當我們必須使用 LIKE、CHARINDEX、SUBSTRING 及類似命令來解析值與列值的組合時，SQL 范式遭到破壞，數(shù)據(jù)可搜索性變差。

因此，規(guī)范化我們的數(shù)據(jù)庫對簡化開發(fā)和始終如一的高性能至關重要。盡管如此，規(guī)范化還是有很多層次的，而且存在過度規(guī)范化的數(shù)據(jù)庫。良好的規(guī)范化平衡了記錄插入、更新、查詢和刪除的需求。采用最廣泛的最佳實踐是，數(shù)據(jù)庫必須至少規(guī)范化到第三范式(Third Normal Form，簡稱 3NF)。但是，第四(4NF)和第五(5NF)范式也相當有用，容易理解，也值得我們努力了解如何使用它們。

冗余記錄

冗余表和字段對數(shù)據(jù)庫設計人員和管理員來說是噩夢。它們需要占用系統(tǒng)資源才能保持安全、更新和備份。當我們討論十多個記錄時，冗余記錄也許看起來不多。但是，在大型數(shù)據(jù)庫中，冗余字段可以是數(shù)千個或數(shù)百萬個，計算資源開銷很大。它們不必要地增加了數(shù)據(jù)庫的規(guī)模，降低了效率，增加了數(shù)據(jù)崩潰的風險。

當然，有時候冗余也許是必要的，但是，這應該是例外，而不是規(guī)則。即使允許冗余，也應當清楚地記錄理由，以確保將來該理由不再有效時，數(shù)據(jù)庫管理員可以刪除冗余。

糟糕的索引

有時候，用戶或應用程序可能需要查詢一張表中的多個列。隨著表中行的數(shù)量的增長，用于完成這些查詢的時間也在穩(wěn)步增加。為了加速查詢并減少表規(guī)模的影響，謹慎的做法是索引表的列，以便在調(diào)用 SELECT 查詢時，每個列中的條目幾乎可以立即獲得。

不幸的是，加速 SELECT 函數(shù)通常會導致更常規(guī)的 INSERT、UPDATE 及 DELETE 命令的性能惡化。這很大程度上是因為索引本身必須不斷地與數(shù)據(jù)庫的內(nèi)容保持同步，而這又意味著大量的數(shù)據(jù)庫引擎開銷。因此，具有諷刺意味的是，我們加速 SELECT 查詢的嘗試可能導致整個數(shù)據(jù)庫變慢。這是過度索引的經(jīng)典案例。

對所有列只提供一個索引，并且該索引和查詢表所用到的主鍵不同，這種方法可以解決這個問題。我們也可能按最常用到最不常用對列進行排序。索引始終是一個微妙的平衡，歸根結(jié)底要用對。

所有域值的一個表

包羅萬象的域表不是數(shù)據(jù)庫設計的最佳方法。請記住，關系數(shù)據(jù)庫的構(gòu)建思想：數(shù)據(jù)庫中的每個對象只代表一個事物。任何數(shù)據(jù)集所代表的事物都不應該含糊不清。通過查看主鍵、表名、列名和關系，我們應該可以快速解讀數(shù)據(jù)集的意義。盡管如此，對于數(shù)據(jù)庫設計，一種揮之不去的誤解是，表越多，數(shù)據(jù)庫就越混亂越復雜。

通常，把幾張表壓縮到一張表中就是簡化設計的原理。這聽上去是個好主意，但是，通常得到的是效率低下且難以操作的數(shù)據(jù)庫。SQL 代碼將變得很長，難以閱讀，也不自然。這將把兩種截然不同的東西混在一起。乍一看，域表看起來像一個抽象的文本容器。從實現(xiàn)的角度來看，這是正確的，但是，這不是設計數(shù)據(jù)庫的最好方法。

作為規(guī)范化過程的一部分，隔離和分解數(shù)據(jù)最終形成每一行只代表一個事物。每個域表與所有其他域表都不同。

多個域表的最終結(jié)果是：

使用在查詢中的數(shù)據(jù)變得更容易。

可以更自然地用外鍵約束來驗證數(shù)據(jù)，這對單域表設計來說是不切實際的。我們可以用單域表來做，但是每張表所需的鍵將使維護變成雷區(qū)。

無論何時我們需要添加與某個對象相關的更多數(shù)據(jù)，該任務就像添加一個或多個列那樣簡單。

小型域表可以放入硬盤的單個頁中，而不像大型域表需要分散在多個硬盤分區(qū)中。表存放在單個頁中意味著可以用單次硬盤讀來完成數(shù)據(jù)提取。

擁有多個域表并不妨礙我們對所有行使用一個編輯器。域表最有可能擁有相同的底層用法 / 結(jié)構(gòu)。

糟糕的或不一致的命名約定

數(shù)據(jù)庫設計人員和開發(fā)人員常常把他們的角色完全看作是技術角色。非技術方面(如遵守命名約定)往往被推到優(yōu)先級列表的較低位置，或者甚至完全被忽略。這可能是個災難性的錯誤。

命名也許是設計人員自行決定的，但是，事實上，它是數(shù)據(jù)庫文檔的第一個也是最重要的元素(我們接下來將探討文檔錯誤)。數(shù)據(jù)庫設計人員應該把他們的工作看作是在他們換了雇主或角色之后還將繼續(xù)存在的東西。命名約定的目的是，讓沒有完全參與該項目的人也能比較容易地快速理解表和列的內(nèi)容。未來的管理員、開發(fā)人員或用戶不應當必須看完長長的文檔才能理解某個表名或列名的意義。表如何命名的具體細節(jié)并未得到業(yè)界的一致同意。

最重要的是一致性。一旦我們遵循某個特定的風格來命名對象，那么在整個數(shù)據(jù)庫中要堅持使用它。表名必須盡可能是表所代表的內(nèi)容的完整或簡約描述，而列名應該清楚地表明其所代表的信息。對于簡單數(shù)據(jù)庫，這并不難。但是，一旦我們構(gòu)建彼此引用的表，事情就變得復雜了。嚴格遵循命名約定始終是正確的方向。

這樣的約定包括沒有列或表名的字符長度限制，以消除使用不易理解或記憶的首字母縮略詞的需要。如列名 CUST_DSCR，任何人讀到這個名字都將不得不猜測該列包含的內(nèi)容。CUSTOMER_DESCRIPTION 則是個更好的列名，沒有迫使讀者展開他們的想象力。

避免冗余：在一張名為“Students(學生)”的表中，我們不必把列命標成 StudentName、StudentAddress 或 StudentGrade，因為 Name、Address 和 Grade 已經(jīng)足夠了。還有，不要使用保留字。用“Index”來標記某列會讓人困惑，也會成為錯誤的來源�？梢杂靡粋�描述性的前綴，如 StudentIndex。

糟糕的文檔

如果數(shù)據(jù)庫開發(fā)人員和設計人員在確定命名約定的優(yōu)先級上碰到問題，那么他們在文檔方面就會存在更大的問題。對于開發(fā)人員來說，文檔有時感覺像是開發(fā)過程中一個微不足道的非必要方面。然而，很多在其他方面設計優(yōu)秀的數(shù)據(jù)庫已經(jīng)犧牲在糟糕文檔的祭壇上。糟糕的文檔極大地抑制了故障排除、結(jié)構(gòu)改進、升級和連續(xù)性。

數(shù)據(jù)庫設計人員必須始終想象他們會在某個時刻不再參與對該數(shù)據(jù)庫的支持。文檔應該讓其他人容易接手數(shù)據(jù)庫設計、開發(fā)或管理。良好的文檔必須包含列、表、關系和約束的定義，使之清楚地表明每個元素應該如何使用。如果我們可以包含示例以說明預期值，那么效果會更好。

有些設計人員會使用糟糕的文檔作為確保工作安全性的一種手段，即除了他們之外，沒有人能完全理解該數(shù)據(jù)庫。這是一種短視和注定失敗的策略，因為這幾乎總是導致管理層看透設計人員的意圖。糟糕的文檔還讓我們作為設計人員多年后返工或改進這些代碼變得非常困難。

測試不充分

我們可以仔細地完成世界級數(shù)據(jù)庫設計所要求的所有步驟。但是，如果我們沒有對數(shù)據(jù)庫進行嚴格的測試，那么我們將陷入黑暗之中。不幸的是，當項目延期時，測試階段受到的影響最大。這是弄巧成拙，因為一個快速通過的數(shù)據(jù)庫會立即被錯誤及不一致性所困擾，而這些錯誤應該很容易在測試階段被識別和解決。

一個滿是缺陷的數(shù)據(jù)庫不會讓用戶和管理員喜歡，即使最終修復了錯誤，我們也擺脫不了不好的名聲。在數(shù)據(jù)庫上線前，進行深入而廣泛地測試，這將大大減少部署到生產(chǎn)環(huán)境中后產(chǎn)生的故障的數(shù)量和規(guī)模。良好的測試不會找到每個錯誤，但是肯定有助于擺脫大多數(shù)錯誤。

結(jié)論

數(shù)據(jù)庫開發(fā)和設計是任何數(shù)據(jù)密集型項目的核心，這些項目幾乎包含了所有業(yè)務應用程序。因此，設計過程應該始終在此上下文中進行審查。本文中列出的設計錯誤一開始會被看作是小而不起眼的問題。然而，最終，它們會極大地降低數(shù)據(jù)庫性能并且修復成本高昂。要從一開始就正確地做事，增加構(gòu)建非常適合其預期目的數(shù)據(jù)庫的幾率。

閱讀英文原文：9 of the Most Common Mistakes in Database Design

標簽： [db:TAGG]

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。