高性能應用程序的數據庫設計最佳實踐

要使應用程序具有良好的性能，您需要強大的應用程序服務器、有保證且充足的帶寬以及出色的編程工作。 但是有一個方面並不總是被考慮在內，它通常會對任何應用程序的性能產生很大影響：數據庫設計。

我們現在將研究數據庫設計最佳實踐，以確保數據訪問不是對應用程序性能產生負面影響的瓶頸。

一個好的數據庫設計的目的是什麼？

除了提高數據訪問性能之外，良好的設計還可以獲得其他好處，例如保持數據的一致性、準確性和可靠性，並通過消除冗餘來減少存儲空間。 良好設計的另一個好處是數據庫更易於使用和維護。 任何必須管理它的人只需要查看實體關係圖 (ERD) 即可了解其結構。

ERD 是數據庫設計的基本工具。 它們可以在三個設計級別創建和可視化：概念、邏輯和物理。

概念設計顯示了一個非常概括的圖表，僅包含與項目利益相關者就標準達成一致所必需的元素，他們不需要了解數據庫的技術細節。 邏輯設計以與數據庫無關的方式詳細顯示實體及其關係。

您可以使用許多工具來促進從 ERD 設計數據庫。 其中最好的是DbSchema 、 SqlDBM和Vertabelo 。

數據庫架構

DbSchema 允許您直觀地設計和管理 SQL、NoSQL 或云數據庫。 該工具允許您在計算機上設計架構並將其部署到多個數據庫並在 HTML5 圖表中生成文檔、編寫查詢以及可視化探索數據等。 它還提供模式同步、隨機數據生成和自動完成的 SQL 代碼編輯。

SqlDBM

SqlDBM 是最好的數據庫圖表設計工具之一，因為它提供了一種在任何瀏覽器中設計數據庫的簡單方法。 使用它不需要其他數據庫引擎或建模工具，儘管 SqlDBM 允許您從現有數據庫中導入模式。 它非常適合團隊合作，因為它允許您與同事共享設計項目。

維塔貝洛

Vertabelo 是一個在線可視化數據庫設計工具，可讓您從邏輯上設計數據庫並自動導出物理模式。 它可以逆向工程，從現有數據庫生成圖表，並通過區分所有者、編輯者和查看者的訪問權限來控制對圖表的訪問。

最後，物理設計是向 ERD 添加所有必要細節的設計，以將其轉變為特定 DBMS 中的可用數據庫，例如 MySQL、MariaDB、MS SQL Server 或任何其他數據庫。 讓我們看一下在設計 ERD 時要牢記的最佳實踐，以使生成的數據庫發揮最佳作用。

定義要設計的數據庫類型

通常區分兩種基本類型的數據庫：關係型和維度型。

關係數據庫用於對數據執行事務的傳統應用程序——也就是說，它們從數據庫中獲取信息、處理它並存儲結果。

另一方面，維度數據庫用於創建數據倉庫：用於數據分析和數據挖掘以獲得洞察力的大型信息存儲庫。

任何數據庫設計任務的第一步都是選擇兩種主要數據庫類型之一來使用：關係型或維度型。 在開始設計之前弄清楚這一點至關重要。 否則，您很容易陷入設計錯誤，最終會導致許多問題並且難以（或不可能）糾正。

採用命名約定

數據庫設計中使用的名稱是必不可少的，因為一旦在數據庫中創建對象，更改其名稱可能是致命的。 僅更改名稱的一個字母可能會破壞依賴關係、關係甚至整個系統。

這就是為什麼使用健康的命名約定至關重要：一組規則可以讓您免於嘗試 50 種不同的可能性來查找您不記得的對象的名稱。

對於命名約定應該如何完成其​​工作，沒有通用指南。 但重要的是在命名數據庫中的任何對象之前建立命名約定並永遠保持該約定。 命名約定建立了指導方針，例如是使用下劃線分隔單詞還是直接連接它們，是使用全部大寫字母還是大寫單詞（Camel Case 風格），是使用複數還是單數來命名對像等等。

從概念設計開始，然後是邏輯設計，最後是物理設計。

這是事物的自然規律。 作為設計人員，您可能會傾向於直接在 DBMS 上創建對像以跳過步驟。 但這將阻止您擁有與利益相關者討論以確保設計滿足業務需求的工具。

在概念設計之後，您必須繼續進行邏輯設計，以獲得足夠的文檔來幫助程序員理解數據庫結構。 保持邏輯設計更新以獨立於要使用的數據庫引擎是至關重要的。 這樣，如果您最終將數據庫遷移到不同的引擎，邏輯設計仍然有用。

最後，物理設計可以由程序員自己或 DBA 創建，採用邏輯設計並添加在特定 DBMS 上實現它所需的所有實現細節。

創建和維護數據字典

即使 ERD 清晰且具有描述性，您也應該添加數據字典以使其更加清晰。 數據字典在數據庫設計中保持連貫性和一致性，特別是當其中的對像數量顯著增長時。

數據字典的主要目的是維護有關數據模型實體及其屬性的參考信息的單一存儲庫。 數據字典應包含所有實體的名稱、所有屬性的名稱、它們的格式和數據類型，以及每個實體的簡要說明。

數據字典為構成數據庫的所有元素提供了清晰簡潔的指南。 這避免了創建表示同一事物的多個對象，這使得當您需要查詢或更新信息時很難知道使用哪個對象。

保持一致的主鍵標準

使用自然鍵或代理鍵的決定必須在數據模型中保持一致。 如果數據模型中的實體具有可以作為各自表的主鍵有效管理的唯一標識符，則無需創建代理鍵。

但是，實體通常由不同類型的多個屬性（日期、數字和/或長字符串）來標識，這對於形成主鍵可能效率低下。 在這些情況下，最好創建整數類型的代理鍵，這樣可以最大限度地提高索引管理效率。 如果實體缺少唯一標識它的屬性，則代理鍵是唯一的選擇。

為每個屬性使用正確的數據類型。

某些數據讓我們可以選擇使用哪種數據類型來表示它們。 例如，日期。 我們可以選擇將它們存儲在日期類型字段、日期/時間類型字段、varchar 類型字段甚至數字類型字段中。 另一種情況是不用於數學運算但用於識別實體的數字數據，例如駕駛執照號碼或郵政編碼。

在日期的情況下，使用引擎的數據類型很方便，這使得操作數據更容易。 如果您只需要存儲事件的日期而不指定時間，則要選擇的數據類型將是簡單的 Date； 如果您需要存儲某個事件發生的日期和時間，則數據類型應為 DateTime。

使用其他類型（例如 varchar 或 numeric）來存儲日期可能很方便，但僅限於非常特殊的情況。 例如，如果事先不知道日期將以何種格式表示，則將其存儲為 varchar 會很方便。 如果搜索性能、排序或索引在處理日期類型字段時至關重要，則之前轉換為浮點數可能會有所不同。

不涉及數學運算的數字數據應表示為 varchar，在記錄中應用格式驗證以避免不一致或重複。 否則，您將面臨某些數據超出數字字段限制的風險，並迫使您在設計已經投入生產時對其進行重構。

查找表的使用

一些沒有經驗的設計者可能認為過度使用查找表來規範化設計會使數據庫的 ERD 不必要地複雜化，因為它添加了大量的“衛星”表，這些表有時只包含少量元素。 那些認為這一點的人應該明白，使用查找表的好處多於壞處。 如果 ERD 的複雜性或大小是一個問題，有一些 ERD 設計工具可以讓您以不同的方式可視化圖表，以便理解它們，儘管它們很複雜。

此示例查詢說明了在精心設計的數據庫中正確使用查找表：

 SELECT StreetName, StreetNumber, Cities.Name AS City, States.Name AS State FROM Addresses INNER JOIN Cities ON Cities.CityId = Addresses.CityId INNER JOIN States ON States.StateId = Addresses.StateId

在這種情況下，我們使用 Cities 和 States 的查找表。

查找表的好處包括減少數據庫的大小、提高搜索性能以及對字段可以包含的有效數據集施加限制等。 對於所有查找表來說，最好包含一個 Bit 或 Boolean 字段來指示表中的記錄是正在使用還是已過時。 此字段可用作過濾器，以避免將過時的元素作為應用程序 UI 中的選項。

根據數據庫類型進行規範化或反規範化

在用於傳統應用程序的關係數據庫中，規範化是必須的。 眾所周知，標準化通過避免冗餘來減少所需的存儲空間。 它提高了信息的質量，並提供了多種工具來優化複雜查詢的性能。

然而，在其他類型的數據庫中，應用了一種稱為非規範化的技術。 在用作數據倉庫的維度數據庫中，非規範化在模式表中添加了某些有用的冗餘信息。

儘管它們似乎是相反的概念，但非規範化並不意味著取消規範化。 它實際上是一種在規範化數據模型後應用於數據模型以簡化查詢編寫和報告的優化技術。

在零件中設計物理模型

在軟件開發項目中，數據庫設計人員向利益相關者展示了一個大型概念模型，其中沒有顯示實現細節。 反過來，為了與開發人員合作，設計人員必須提供一個物理模型，其中包含每個實體和屬性的所有細節。 但是，這兩個模型都不需要在項目開始時完全創建。

在應用敏捷方法時，每個開發週期開始時的每個開發人員都會在該週期內處理一個或多個用戶故事。 數據庫設計人員的工作是為每個開發人員提供一個物理子模型，該子模型僅包含他們工作單元所需的對象。

在每個開發週期結束時，將在該週期中創建的子模型合併，以便完整的物理模型與應用程序的開發並行形成。

善用視圖和索引

視圖和索引是數據庫設計中用於提高應用程序性能的兩個基本工具。 視圖的使用允許處理簡化查詢的抽象，隱藏不必要的表細節。 反過來，視圖使數據庫引擎的查詢優化任務更容易，因為它們允許它們預測如何獲取數據並選擇最佳策略以更快地提供查詢結果。

一旦數據庫投入生產，索引可以根據用戶體驗提高慢查詢的性能。 但是，索引創建可以作為數據庫設計任務的一部分來完成，預測應用程序的需求。

對於創建索引，您需要大致了解每個表的大小（就記錄數而言），然後為更大的表創建索引。 要選擇要包含在索引中的字段，您必須主要考慮表示外鍵的字段以及將在搜索中用作過濾器的字段。

當你認為工作已經完成時，是時候重構了。

數據庫的設計總是可以改進的。 當由於新需求或新業務需求而沒有對數據庫進行更改時，這是執行改進設計的重構過程的好機會。 重構的意思很簡單：在不影響數據庫語義的情況下引入改進設計的更改。

有許多重構技術可以改進數據庫的設計，但超出了本文的範圍，但最好知道它們的存在以便在需要時使用它們。

每當您需要設計數據庫時，手頭有此最佳實踐列表將使您獲得最佳結果，以便應用程序始終保持數據訪問的最佳性能。