1. 為什么要關(guān)注數(shù)據(jù)庫(kù)設(shè)計(jì)?
無(wú)論是應(yīng)用程序,還是數(shù)據(jù)庫(kù)如何變化,數(shù)據(jù)始終是最重要的部分。通常,數(shù)據(jù)是系統(tǒng)存在的首要目的。這就是為什么,我們不應(yīng)該只把數(shù)據(jù)庫(kù)系統(tǒng)看作是保存數(shù)據(jù)的黑盒子,而要將其看成驗(yàn)證和防止數(shù)據(jù)腐化的工具。
要做到這一點(diǎn),就要有健壯和深思熟慮的數(shù)據(jù)庫(kù)設(shè)計(jì)。當(dāng)然,業(yè)務(wù)邏輯是在應(yīng)用層編碼,它確保數(shù)據(jù)在到達(dá)數(shù)據(jù)庫(kù)之前的格式是正確的。
但是,誰(shuí)能保證網(wǎng)絡(luò)故障或缺陷不會(huì)放行不可靠的“客人”?此外,應(yīng)用層并不是通往數(shù)據(jù)庫(kù)的唯一的“門”。我們可以使用導(dǎo)入腳本、維護(hù)腳本,DBA 和開(kāi)發(fā)人員也會(huì)與之交互。我們可以在底層采取預(yù)防措施確保在數(shù)據(jù)存儲(chǔ)前總是進(jìn)行檢查。
擁有健壯、可靠的數(shù)據(jù)也有助于開(kāi)發(fā)和測(cè)試。將一個(gè)列設(shè)置為 Not Null 可以省掉許多假設(shè)該列為空的測(cè)試場(chǎng)景,還能簡(jiǎn)化代碼,讓開(kāi)發(fā)人員不用(幾乎)每次訪問(wèn)它之前都檢查值。
在強(qiáng)調(diào)了良好的數(shù)據(jù)庫(kù)設(shè)計(jì)的重要性后,讓我們看看可以使用哪些工具來(lái)實(shí)現(xiàn)它。
2. 規(guī)范化
這無(wú)疑是良好設(shè)計(jì)的首要原則。這里,我們不打算深入研究規(guī)范化規(guī)則,只是想強(qiáng)調(diào)它的重要性。
關(guān)于這個(gè)話題,這里有份不錯(cuò)的資料,你可以進(jìn)一步閱讀。
https://docs.microsoft.com/en-us/office/troubleshoot/access/database-normalization-description
3. 數(shù)據(jù)類型
另一件要注意的事情是定義適當(dāng)?shù)膶傩灶愋?/strong>。這不僅可以提高數(shù)據(jù)庫(kù)的性能,還能在存儲(chǔ)數(shù)據(jù)前驗(yàn)證數(shù)據(jù)。所以,我們應(yīng)該在“integer”、“numeric”字段中保存數(shù)值數(shù)據(jù);在“timestamp”、“timestamptz”字段中保存時(shí)間戳;在“bit”、“char(1)”或“boolean”字段中保存布爾值等等。
日期值得特別注意。如果 Date 屬性假設(shè)只有日期部分(OrderDate,ReleaseDate),請(qǐng)使用沒(méi)有時(shí)間部分的 Date 類型。如果你只需要保留時(shí)間(StartTime,EndTime),就使用合適的時(shí)間類型。
如果不需要指定精度,則將其指定為零(“time(0)”)。對(duì)帶有時(shí)間部分的日期,有一個(gè)問(wèn)題是,你必須總是截?cái)鄷r(shí)間部分,只顯示日期,并且當(dāng)你要在與數(shù)據(jù)庫(kù)所在時(shí)區(qū)不同的地方顯示時(shí),要確保格式化后不會(huì)顯示成昨天或明天。當(dāng)跳轉(zhuǎn)到夏令時(shí)的時(shí)候,帶有時(shí)間部分的日期時(shí)間加減也可能出現(xiàn)問(wèn)題。
4. 約束
約束是本文討論的重點(diǎn)。它們將無(wú)效數(shù)據(jù)排除在外,并確保數(shù)據(jù)的健壯性。讓我們一個(gè)一個(gè)來(lái)看。
非空約束
如果業(yè)務(wù)規(guī)則要求該屬性應(yīng)該始終存在,那么要毫不猶豫地將其設(shè)置為 Not Null。適合設(shè)置為 Not Null 的字段有 Id、Name、AddedDate、IsActive、State、CategoryId(如果所有項(xiàng)都應(yīng)該有一個(gè)類別)、ItemCount、Price 以及許多其他字段。通常,這些屬性在業(yè)務(wù)邏輯中扮演重要角色。其他可選的信息字段可能還是可以設(shè)置為 Null。
但是要注意,不要對(duì)可以為空的屬性使用 Not Null 約束。例如,一個(gè)長(zhǎng)時(shí)間運(yùn)行的任務(wù)總有一個(gè) StartTimestamp(Not Null),但是只有在任務(wù)完成時(shí)才更新 EndTimestamp(Null)。
另一個(gè)典型的例子是,Employee 表的 ManagerId,并不是所有員工都有經(jīng)理。不要試圖讓 ManagerId 不為空,并為沒(méi)有經(jīng)理的員工插入“0”或“-1”。當(dāng)我們添加外鍵約束時(shí),這將導(dǎo)致其他問(wèn)題。
唯一約束
同樣,根據(jù)業(yè)務(wù)規(guī)則,一些屬性(或?qū)傩缘慕M合)應(yīng)該是惟一的,比如 Id、PinNumber、BookId 和 AuthorId、OrderNo 等。應(yīng)該通過(guò)添加惟一約束來(lái)保證這些屬性的惟一。
還有一點(diǎn)要注意:可以使用唯一索引來(lái)實(shí)現(xiàn)同樣的效果,但是添加約束是更好的方法。因?yàn)楫?dāng)添加惟一約束時(shí),會(huì)自動(dòng)創(chuàng)建非惟一索引。
因此,如果出于某種原因,你必須臨時(shí)禁用 / 啟用約束,將會(huì)非常容易。在使用唯一索引的情況下,你必須刪除 / 重新創(chuàng)建索引,從性能和時(shí)間方面來(lái)說(shuō),這是一個(gè)昂貴的操作。
主鍵
Not Null 和唯一約束一起構(gòu)成主鍵。當(dāng)我們想到主鍵時(shí),會(huì)很快想到 Id 或 ObjectId 之類的列。但是主鍵也可以是復(fù)合的,比如 BookId 和 AuthorId。
這里有個(gè)難題是,是使用單獨(dú)的 Id 列作為主鍵,還是將兩者的組合作為主鍵?通常,使用單獨(dú)的 Id 列是一種更好的方法,因?yàn)樗梢允惯B接更加清晰,還能方便地將另一列添加到惟一組合中。但是,即使有了一個(gè)單獨(dú)的主鍵(Id),我們還是要為 BookId 和 AuthorId 列添加唯一約束。
Check 約束
Check 約束允許我們定義數(shù)據(jù)的有效值 / 范圍。適合 Check 約束的屬性有百分比(0 到 100 之間)、狀態(tài)(0、1、2)、價(jià)格、金額、總數(shù)(大于或等于 0)、PinNumber(固定長(zhǎng)度)等。
同樣,不要嘗試將業(yè)務(wù)邏輯編碼到 Check 約束中。我記得有一次,在 AccountBalance 列中添加了一個(gè)“大于或等于零”的 Check 約束,從而避免了意外透支。
默認(rèn)約束
默認(rèn)約束也很重要。它們?cè)试S我們向現(xiàn)有表中添加新的 Not Null 列,并使“舊”API 與新結(jié)構(gòu)兼容,直到所有各方都完成升級(jí)(盡管在完全升級(jí)后,默認(rèn)約束應(yīng)該刪除)。
這里要記住一點(diǎn)。不要在默認(rèn)約束中編寫(xiě)業(yè)務(wù)邏輯。例如,函數(shù)“now()”可能很適合(盡管不總是)作為日志表中的時(shí)間戳字段的默認(rèn)值,但不適合 Orders 表的 OrderDate 字段。你可能會(huì)傾向于在插入語(yǔ)句中省略 OrderDate,而依賴于默認(rèn)約束,但這意味著將業(yè)務(wù)邏輯擴(kuò)展到數(shù)據(jù)庫(kù)層。
此外,在某些情況下,業(yè)務(wù)可能只在訂單批準(zhǔn)后才給 OrderDate 賦值,因?yàn)槟J(rèn)約束深埋在數(shù)據(jù)庫(kù)中,所以,當(dāng)我們對(duì)應(yīng)用層的代碼進(jìn)行更改時(shí),它不會(huì)那么明顯。
外鍵約束
外鍵約束是關(guān)系數(shù)據(jù)庫(kù)設(shè)計(jì)之王。外鍵與主鍵一起確保表之間的數(shù)據(jù)一致性。規(guī)范化規(guī)則告訴我們何時(shí)將數(shù)據(jù)提取到表中并使用外鍵引用它。這里我們將關(guān)注細(xì)節(jié)差別,比如 OnDelete 和 OnUpdate 規(guī)則。
讓我們從簡(jiǎn)單的部分開(kāi)始:OnUpdate。外鍵引用主鍵,它們很少(如果有的話)被修改。因此,OnUpdate 規(guī)則不是很常用,但將其設(shè)置為 Cascade 還是有意義的,因?yàn)槲覀冇袝r(shí)可能必須更新某些行的主鍵(通常在遷移后)。這樣,數(shù)據(jù)庫(kù)將允許我們進(jìn)行更新,并將新的 id 傳播到子表中。
OnDelete 規(guī)則有點(diǎn)復(fù)雜。根據(jù)數(shù)據(jù)庫(kù)的不同,我們有 NoAction、Restrict、SetNull、SetDefault 和 Cascade 選項(xiàng)。那么,選擇哪一個(gè)呢?
通常,對(duì)于鍵引用查找或不引用實(shí)體的實(shí)體,我們選擇 NoAction。例如,Products -> Categories、Books -> Authors 等。在大多數(shù)情況下,Restrict 與 NoAction 是相同的,但是對(duì)于某些數(shù)據(jù)庫(kù),它們有細(xì)微的區(qū)別。
https://www.vertabelo.com/blog/on-delete-restrict-vs-on-delete-no-action/
另一方面,當(dāng)子記錄不能在沒(méi)有父記錄的情況下存在時(shí),選擇 Cascade。在 Book 和 Author 示例中,當(dāng)刪除一本書(shū)時(shí),我們也應(yīng)該從 BookAuthor 表中刪除記錄。其他例子有 OrderDetails -> Orders、PostComments -> Posts 等。這里,有些人可能會(huì)不同意,數(shù)據(jù)庫(kù)不應(yīng)該自動(dòng)刪除子行,它們應(yīng)該由應(yīng)用層刪除。根據(jù)業(yè)務(wù)邏輯,是這樣的。但有時(shí)“不重要的”子項(xiàng)刪除可以委托給數(shù)據(jù)庫(kù)。
SetNull 很少使用。例如,Employee.ManagerId 和 Employee.Id 之間的外鍵可以是 SetNull。當(dāng)一名經(jīng)理被撤職,他的下屬就沒(méi)經(jīng)理了。顯然,只有當(dāng)列可為空時(shí)才能選擇該項(xiàng)規(guī)則。
在這些規(guī)則中,SetDefault 最罕見(jiàn)。當(dāng)父記錄被刪除時(shí),它將列設(shè)置為其默認(rèn)值。因?yàn)橥怄I引用主鍵,我們很難想象一個(gè)有外鍵的字段將默認(rèn)值硬編碼。但無(wú)論如何,這個(gè)選項(xiàng)是存在的,我們還是有可能需要它。
5. 索引
索引是良好數(shù)據(jù)庫(kù)設(shè)計(jì)的重要組成部分,但有點(diǎn)偏離我們的討論,因?yàn)樗鼈儙缀醪荒鼙Wo(hù)我們的數(shù)據(jù)(惟一索引除外)。
需要注意的一點(diǎn)是:一些 RDBMS 系統(tǒng)(例如 Oracle)會(huì)在創(chuàng)建外鍵時(shí)自動(dòng)創(chuàng)建索引,而無(wú)需我們操心。其他數(shù)據(jù)庫(kù)(例如 MS SQL Server)不會(huì)這樣做,我們必須自己添加索引。
6. 小結(jié)
一個(gè)深思熟慮的設(shè)計(jì)可以為我們節(jié)省大量的編碼、測(cè)試和故障排除時(shí)間。在設(shè)計(jì)良好的數(shù)據(jù)庫(kù)上編寫(xiě)查詢和報(bào)表令人愉快。將數(shù)據(jù)發(fā)布并遷移到新系統(tǒng)也會(huì)非常容易。
以上就是W3Cschool編程獅
關(guān)于怎樣實(shí)現(xiàn)良好的數(shù)據(jù)庫(kù)設(shè)計(jì)?的相關(guān)介紹了,希望對(duì)大家有所幫助。