如何實現(xiàn)良好的數(shù)據(jù)庫設(shè)計

本篇內(nèi)容介紹了“如何實現(xiàn)良好的數(shù)據(jù)庫設(shè)計”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)是由多位在大型網(wǎng)絡(luò)公司、廣告設(shè)計公司的優(yōu)秀設(shè)計人員和策劃人員組成的一個具有豐富經(jīng)驗的團隊，其中包括網(wǎng)站策劃、網(wǎng)頁美工、網(wǎng)站程序員、網(wǎng)頁設(shè)計師、平面廣告設(shè)計師、網(wǎng)絡(luò)營銷人員及形象策劃。承接：做網(wǎng)站、成都做網(wǎng)站、網(wǎng)站改版、網(wǎng)頁設(shè)計制作、網(wǎng)站建設(shè)與維護、網(wǎng)絡(luò)推廣、數(shù)據(jù)庫開發(fā),以高性價比制作企業(yè)網(wǎng)站、行業(yè)門戶平臺等全方位的服務(wù)。

1. 為什么要關(guān)注數(shù)據(jù)庫設(shè)計？

無論是應(yīng)用程序，還是數(shù)據(jù)庫如何變化，數(shù)據(jù)始終是最重要的部分。通常，數(shù)據(jù)是系統(tǒng)存在的首要目的。這就是為什么，我們不應(yīng)該只把數(shù)據(jù)庫系統(tǒng)看作是保存數(shù)據(jù)的黑盒子，而要將其看成驗證和防止數(shù)據(jù)腐化的工具。

要做到這一點，就要有健壯和深思熟慮的數(shù)據(jù)庫設(shè)計。當然，業(yè)務(wù)邏輯是在應(yīng)用層編碼，它確保數(shù)據(jù)在到達數(shù)據(jù)庫之前的格式是正確的。

但是，誰能保證網(wǎng)絡(luò)故障或缺陷不會放行不可靠的“客人”？此外，應(yīng)用層并不是通往數(shù)據(jù)庫的唯一的“門”。我們可以使用導(dǎo)入腳本、維護腳本，DBA 和開發(fā)人員也會與之交互。我們可以在底層采取預(yù)防措施確保在數(shù)據(jù)存儲前總是進行檢查。

擁有健壯、可靠的數(shù)據(jù)也有助于開發(fā)和測試。將一個列設(shè)置為 Not Null 可以省掉許多假設(shè)該列為空的測試場景，還能簡化代碼，讓開發(fā)人員不用（幾乎）每次訪問它之前都檢查值。

在強調(diào)了良好的數(shù)據(jù)庫設(shè)計的重要性后，讓我們看看可以使用哪些工具來實現(xiàn)它。

2. 規(guī)范化

這無疑是良好設(shè)計的首要原則。這里，我們不打算深入研究規(guī)范化規(guī)則，只是想強調(diào)它的重要性。

關(guān)于這個話題，這里有份不錯的資料，你可以進一步閱讀。

https://docs.microsoft.com/en-us/office/troubleshoot/access/database-normalization-description

3. 數(shù)據(jù)類型

另一件要注意的事情是定義適當?shù)膶傩灶愋?。這不僅可以提高數(shù)據(jù)庫的性能，還能在存儲數(shù)據(jù)前驗證數(shù)據(jù)。所以，我們應(yīng)該在“integer”、“numeric”字段中保存數(shù)值數(shù)據(jù)；在“timestamp”、“timestamptz”字段中保存時間戳；在“bit”、“char(1)”或“boolean”字段中保存布爾值等等。

日期值得特別注意。如果 Date 屬性假設(shè)只有日期部分（OrderDate，ReleaseDate），請使用沒有時間部分的 Date 類型。如果你只需要保留時間（StartTime，EndTime），就使用合適的時間類型。

如果不需要指定精度，則將其指定為零（“time(0)”）。對帶有時間部分的日期，有一個問題是，你必須總是截斷時間部分，只顯示日期，并且當你要在與數(shù)據(jù)庫所在時區(qū)不同的地方顯示時，要確保格式化后不會顯示成昨天或明天。當跳轉(zhuǎn)到夏令時的時候，帶有時間部分的日期時間加減也可能出現(xiàn)問題。

4. 約束

約束是本文討論的重點。它們將無效數(shù)據(jù)排除在外，并確保數(shù)據(jù)的健壯性。讓我們一個一個來看。

非空約束

如果業(yè)務(wù)規(guī)則要求該屬性應(yīng)該始終存在，那么要毫不猶豫地將其設(shè)置為 Not Null。適合設(shè)置為 Not Null 的字段有 Id、Name、AddedDate、IsActive、State、CategoryId（如果所有項都應(yīng)該有一個類別）、ItemCount、Price 以及許多其他字段。通常，這些屬性在業(yè)務(wù)邏輯中扮演重要角色。其他可選的信息字段可能還是可以設(shè)置為 Null。

但是要注意，不要對可以為空的屬性使用 Not Null 約束。例如，一個長時間運行的任務(wù)總有一個 StartTimestamp（Not Null），但是只有在任務(wù)完成時才更新 EndTimestamp（Null）。

另一個典型的例子是，Employee 表的 ManagerId，并不是所有員工都有經(jīng)理。不要試圖讓 ManagerId 不為空，并為沒有經(jīng)理的員工插入“0”或“-1”。當我們添加外鍵約束時，這將導(dǎo)致其他問題。

唯一約束

同樣，根據(jù)業(yè)務(wù)規(guī)則，一些屬性（或?qū)傩缘慕M合）應(yīng)該是惟一的，比如 Id、PinNumber、BookId 和 AuthorId、OrderNo 等。應(yīng)該通過添加惟一約束來保證這些屬性的惟一。

還有一點要注意：可以使用唯一索引來實現(xiàn)同樣的效果，但是添加約束是更好的方法。因為當添加惟一約束時，會自動創(chuàng)建非惟一索引。

因此，如果出于某種原因，你必須臨時禁用 / 啟用約束，將會非常容易。在使用唯一索引的情況下，你必須刪除 / 重新創(chuàng)建索引，從性能和時間方面來說，這是一個昂貴的操作。

主鍵

Not Null 和唯一約束一起構(gòu)成主鍵。當我們想到主鍵時，會很快想到 Id 或 ObjectId 之類的列。但是主鍵也可以是復(fù)合的，比如 BookId 和 AuthorId。

這里有個難題是，是使用單獨的 Id 列作為主鍵，還是將兩者的組合作為主鍵？通常，使用單獨的 Id 列是一種更好的方法，因為它可以使連接更加清晰，還能方便地將另一列添加到惟一組合中。但是，即使有了一個單獨的主鍵（Id），我們還是要為 BookId 和 AuthorId 列添加唯一約束。

Check 約束

Check 約束允許我們定義數(shù)據(jù)的有效值 / 范圍。適合 Check 約束的屬性有百分比（0 到 100 之間）、狀態(tài)（0、1、2）、價格、金額、總數(shù)（大于或等于 0）、PinNumber（固定長度）等。

同樣，不要嘗試將業(yè)務(wù)邏輯編碼到 Check 約束中。我記得有一次，在 AccountBalance 列中添加了一個“大于或等于零”的 Check 約束，從而避免了意外透支。

默認約束

默認約束也很重要。它們允許我們向現(xiàn)有表中添加新的 Not Null 列，并使“舊”API 與新結(jié)構(gòu)兼容，直到所有各方都完成升級（盡管在完全升級后，默認約束應(yīng)該刪除）。

這里要記住一點。不要在默認約束中編寫業(yè)務(wù)邏輯。例如，函數(shù)“now()”可能很適合（盡管不總是）作為日志表中的時間戳字段的默認值，但不適合 Orders 表的 OrderDate 字段。你可能會傾向于在插入語句中省略 OrderDate，而依賴于默認約束，但這意味著將業(yè)務(wù)邏輯擴展到數(shù)據(jù)庫層。

此外，在某些情況下，業(yè)務(wù)可能只在訂單批準后才給 OrderDate 賦值，因為默認約束深埋在數(shù)據(jù)庫中，所以，當我們對應(yīng)用層的代碼進行更改時，它不會那么明顯。

外鍵約束

外鍵約束是關(guān)系數(shù)據(jù)庫設(shè)計之王。外鍵與主鍵一起確保表之間的數(shù)據(jù)一致性。規(guī)范化規(guī)則告訴我們何時將數(shù)據(jù)提取到表中并使用外鍵引用它。這里我們將關(guān)注細節(jié)差別，比如 OnDelete 和 OnUpdate 規(guī)則。

DBeaver 中的外鍵約束編輯器

讓我們從簡單的部分開始：OnUpdate。外鍵引用主鍵，它們很少（如果有的話）被修改。因此，OnUpdate 規(guī)則不是很常用，但將其設(shè)置為 Cascade 還是有意義的，因為我們有時可能必須更新某些行的主鍵（通常在遷移后）。這樣，數(shù)據(jù)庫將允許我們進行更新，并將新的 id 傳播到子表中。

OnDelete 規(guī)則有點復(fù)雜。根據(jù)數(shù)據(jù)庫的不同，我們有 NoAction、Restrict、SetNull、SetDefault 和 Cascade 選項。那么，選擇哪一個呢？

通常，對于鍵引用查找或不引用實體的實體，我們選擇 NoAction。例如，Products -> Categories、Books -> Authors 等。在大多數(shù)情況下，Restrict 與 NoAction 是相同的，但是對于某些數(shù)據(jù)庫，它們有細微的區(qū)別。

https://www.vertabelo.com/blog/on-delete-restrict-vs-on-delete-no-action/

另一方面，當子記錄不能在沒有父記錄的情況下存在時，選擇 Cascade。在 Book 和 Author 示例中，當刪除一本書時，我們也應(yīng)該從 BookAuthor 表中刪除記錄。其他例子有 OrderDetails -> Orders、PostComments -> Posts 等。這里，有些人可能會不同意，數(shù)據(jù)庫不應(yīng)該自動刪除子行，它們應(yīng)該由應(yīng)用層刪除。根據(jù)業(yè)務(wù)邏輯，是這樣的。但有時“不重要的”子項刪除可以委托給數(shù)據(jù)庫。

SetNull 很少使用。例如，Employee.ManagerId 和 Employee.Id 之間的外鍵可以是 SetNull。當一名經(jīng)理被撤職，他的下屬就沒經(jīng)理了。顯然，只有當列可為空時才能選擇該項規(guī)則。

在這些規(guī)則中，SetDefault 最罕見。當父記錄被刪除時，它將列設(shè)置為其默認值。因為外鍵引用主鍵，我們很難想象一個有外鍵的字段將默認值硬編碼。但無論如何，這個選項是存在的，我們還是有可能需要它。

5. 索引

索引是良好數(shù)據(jù)庫設(shè)計的重要組成部分，但有點偏離我們的討論，因為它們幾乎不能保護我們的數(shù)據(jù)（惟一索引除外）。

需要注意的一點是：一些 RDBMS 系統(tǒng)（例如 Oracle）會在創(chuàng)建外鍵時自動創(chuàng)建索引，而無需我們操心。其他數(shù)據(jù)庫（例如 MS SQL Server）不會這樣做，我們必須自己添加索引。

“如何實現(xiàn)良好的數(shù)據(jù)庫設(shè)計”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！

網(wǎng)站欄目：如何實現(xiàn)良好的數(shù)據(jù)庫設(shè)計
網(wǎng)站網(wǎng)址：http://bm7419.com/article30/pcsepo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供動態(tài)網(wǎng)站、網(wǎng)站建設(shè)、定制網(wǎng)站、微信小程序、ChatGPT、微信公眾號

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)