數(shù)據(jù)庫(kù)設(shè)計(jì)規(guī)范化的五個(gè)要求-資料下載頁(yè)
2025-08-05 07:39本頁(yè)面
【正文】 模型“阻抗不匹配”，當(dāng)然是有不匹配的地方，比方說(shuō)對(duì)象模型當(dāng)中特有的“繼承”，“組合”，“聚合”，“依賴(lài)”的概念在關(guān)系模型當(dāng)中是不存在的，但是這種模型的“阻抗不匹配”最終在存儲(chǔ)模型是還是能夠統(tǒng)一起來(lái)的，這就是ORM的作用： 對(duì)象的繼承關(guān)系可以表達(dá)為三種不同的關(guān)系存儲(chǔ)模型：整個(gè)繼承數(shù)一張表；每個(gè)繼承層次一張表；每個(gè)對(duì)象一張表 對(duì)象的組合和聚合可以用主外鍵關(guān)聯(lián)的表來(lái)存儲(chǔ)，它可以表達(dá)1:n，n:1和n:m的關(guān)系 對(duì)象的依賴(lài)關(guān)系和存儲(chǔ)無(wú)關(guān)，所以不需要ORM做什么。 所以結(jié)論就是這樣： 關(guān)系模型和對(duì)象模型存在概念上的阻抗不匹配，但是在關(guān)系數(shù)據(jù)庫(kù)的存儲(chǔ)模型上是一致的，無(wú)論你從關(guān)系模型的三大范式理論出發(fā)，還是從對(duì)象模型的ORM理論出發(fā)，最終一定會(huì)得到一致的數(shù)據(jù)庫(kù)表設(shè)計(jì)。 這里值得我們反思的一個(gè)問(wèn)題是：為什么傳統(tǒng)的數(shù)據(jù)庫(kù)應(yīng)用人們這樣漠視和違反三大范式？在很多所謂的金融、電信等超級(jí)大項(xiàng)目當(dāng)中，連主鍵都沒(méi)有的表比比皆是，一張表上百個(gè)字段，字段之間沒(méi)有什么邏輯關(guān)系的情況比比皆是？ 我想答案在于：傳統(tǒng)的數(shù)據(jù)庫(kù)應(yīng)用軟件開(kāi)發(fā)，程序員很難從符合三大范式的數(shù)據(jù)模型當(dāng)中獲得有效的查詢(xún)性能。符合三大范式就意味著數(shù)據(jù)庫(kù)表會(huì)拆分的很細(xì)，表間關(guān)聯(lián)很多，統(tǒng)計(jì)分析查詢(xún)就不可避免的導(dǎo)致n張表的聯(lián)合查詢(xún)，在沒(méi)有有效的應(yīng)用層緩存的情況下，這種查詢(xún)無(wú)可避免的性能低下。這使得程序員寧肯違背三大范式，而選擇查詢(xún)性能優(yōu)先的數(shù)據(jù)庫(kù)設(shè)計(jì)。 但是我們現(xiàn)在不一樣了，有了良好的ORM框架和應(yīng)用層的對(duì)象緩存機(jī)制，我們可以做到：讓比較簡(jiǎn)單的查詢(xún)根本不打擾數(shù)據(jù)庫(kù)，讓比較復(fù)雜的查詢(xún)盡量少的掃描表記錄，其最終達(dá)到的效果在OLTP類(lèi)型的應(yīng)用上面效果遠(yuǎn)遠(yuǎn)超過(guò)傳統(tǒng)的方式。 以JavaEye網(wǎng)站為例：JavaEye使用了Rails的ActiveRecord ORM，表設(shè)計(jì)符合三大范式，所有頁(yè)面都是動(dòng)態(tài)頁(yè)面，要對(duì)數(shù)據(jù)庫(kù)發(fā)送大量查詢(xún)，很多Web頁(yè)面至少要向數(shù)據(jù)庫(kù)發(fā)送50條以上的SQL語(yǔ)句。根據(jù)對(duì)數(shù)據(jù)庫(kù)和Memcached Server的統(tǒng)計(jì)數(shù)據(jù)表明：JavaEye網(wǎng)站平均每秒向數(shù)據(jù)庫(kù)發(fā)送140條SQL語(yǔ)句，平均每秒向Memcached Server發(fā)送250次緩存查詢(xún)，緩存命中率大概為85%，也就是說(shuō)緩存服務(wù)器要比數(shù)據(jù)庫(kù)服務(wù)器繁忙將近一倍，而Ruby應(yīng)用程序的數(shù)據(jù)有60%是來(lái)自Memcached Server，而只有40%是直接來(lái)自MySQL的。 為了加深大家印象，再給大家一個(gè)數(shù)據(jù)，目前JavaEye的Web服務(wù)器CPU負(fù)載在4060%左右，而JavaEye的數(shù)據(jù)庫(kù)服務(wù)器CPU負(fù)載只有20%30%，IO WAIT幾乎沒(méi)有。所以良好的遵循三大范式，利用好ORM和對(duì)象緩存，可以取得非常棒的應(yīng)用性能，還可以讓你的數(shù)據(jù)庫(kù)更加輕松。 最后，我的結(jié)論就是對(duì)象模型和關(guān)系模型在數(shù)據(jù)庫(kù)存儲(chǔ)上不存在阻抗不匹配，面向?qū)ο蟮某绦蛟O(shè)計(jì)和面向數(shù)據(jù)庫(kù)的程序設(shè)計(jì)應(yīng)該是一致的，而不應(yīng)該是對(duì)立和沖突的，請(qǐng)不要把面向?qū)ο蠛兔嫦驍?shù)據(jù)庫(kù)對(duì)立起來(lái)，不是他們對(duì)立，而是你不了解什么才是真正良好的設(shè)計(jì)。+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++前提聲明，個(gè)人觀點(diǎn)： 沒(méi)有最好的，只有最合適的。 對(duì)不同的視角，所謂的“最合適”也是不同的。 設(shè)計(jì)總是伴隨者“妥協(xié)”的。 請(qǐng)不要在討論中試圖證明個(gè)人的觀點(diǎn)是“最好的”。 大家都提出自己的經(jīng)驗(yàn)、思路、教訓(xùn)等等，讓參與討論的人根據(jù)自己的條件（這個(gè)我們無(wú)法完全為他人設(shè)想），有所取舍的得到“我所正需要的”。 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 以下是針對(duì)事務(wù)型數(shù)據(jù)庫(kù)： ？個(gè)人傾向于少采用聯(lián)合主鍵。因?yàn)檫@樣會(huì)降低索引的效率，聯(lián)合主鍵一般都要用到至少一個(gè)業(yè)務(wù)字段，往往是字符串型的，而且理論上多字段的索引比單字段的索引要慢些。看上去似乎也不那么清爽。 在實(shí)際的設(shè)計(jì)中，我盡量避免使用聯(lián)合主鍵，有些時(shí)候“不得不”使用聯(lián)合主鍵。 （邏輯主鍵）還是有意義的字段（業(yè)務(wù)主鍵）？個(gè)人傾向于“邏輯主鍵”，理由是這樣設(shè)計(jì)出的數(shù)據(jù)庫(kù)模型結(jié)構(gòu)清晰、關(guān)系脈絡(luò)清楚，往往更符合“第三范式”（雖然不是故意的，呵呵）。而且更容易避開(kāi)“聯(lián)合主鍵”，而且可以使用索引效率高的字段類(lèi)型，比如int、long、number。缺點(diǎn)是用無(wú)意義的字段建立表間的關(guān)系，使跨表查詢(xún)?cè)龆啵氏陆?。（矛盾無(wú)處不在，前面剛說(shuō)完可以提高效率，這里馬上又降低效率）?！皹I(yè)務(wù)主鍵”可以提升查詢(xún)編碼的簡(jiǎn)潔度和效率。 個(gè)人使用實(shí)際狀況，總體來(lái)說(shuō)“邏輯主鍵”比“業(yè)務(wù)主鍵”執(zhí)行效率低，但不會(huì)低到無(wú)法滿足需求。采用“邏輯主鍵”比采用“業(yè)務(wù)主鍵”更利于數(shù)據(jù)庫(kù)模型的結(jié)構(gòu)、關(guān)系清晰，也更便于維護(hù)。 對(duì)于分析型數(shù)據(jù)庫(kù)，如數(shù)據(jù)倉(cāng)庫(kù)，千萬(wàn)不要這樣做。 ？個(gè)人傾向于少使用多對(duì)多關(guān)系。這個(gè)問(wèn)題其實(shí)不是數(shù)據(jù)庫(kù)設(shè)計(jì)的問(wèn)題了，在數(shù)據(jù)庫(kù)設(shè)計(jì)中，多對(duì)多關(guān)系也僅僅存在于邏輯模型（ER）階段，物理模型不在有多對(duì)多關(guān)系，實(shí)際數(shù)據(jù)庫(kù)中也不會(huì)有“多對(duì)多”關(guān)系。這是使用ORM時(shí)的問(wèn)題，比如使用Hibernate，多對(duì)多關(guān)系有時(shí)會(huì)使編碼看起來(lái)靈活一些，代價(jià)是效率的明顯降低。 個(gè)人實(shí)際使用中，設(shè)計(jì)時(shí)基本不考慮多對(duì)多關(guān)系，但編碼時(shí)總會(huì)有小組成員使用一些多對(duì)多關(guān)系，自己建立多對(duì)多的ORM，使自己編碼方便些，用在數(shù)據(jù)量小的地方，影響不大。大數(shù)據(jù)量，則“禁止使用”。 ？我習(xí)慣在設(shè)計(jì)時(shí)給每個(gè)表設(shè)一個(gè)state字段，取值0或1，默認(rèn)值為1，具體業(yè)務(wù)意義或操作上的意義可以自定義?？梢宰鳛橐粋€(gè)狀態(tài)控制字段，如查詢(xún)、更新、刪除條件，單據(jù)是否有效（業(yè)務(wù)單據(jù)對(duì)應(yīng)的表會(huì)有業(yè)務(wù)意義上的“有/無(wú)效”或“狀態(tài)”字段，這種情況下，我還是會(huì)再加一個(gè)state字段），甚至僅僅是控制一條數(shù)據(jù)是否“有效”（有效的意義你自己定）。在數(shù)據(jù)遷移（如轉(zhuǎn)入分析用的數(shù)據(jù)庫(kù)）時(shí)也可能會(huì)發(fā)揮作用。 ？沒(méi)辦法，我總是設(shè)計(jì)不出“完美”的數(shù)據(jù)表，給每個(gè)表加幾個(gè)備用字段（我一般用字符串型，隨你）可以應(yīng)付“不時(shí)之需”，尤其是需要長(zhǎng)期維護(hù)的、業(yè)務(wù)可能有臨時(shí)性變動(dòng)的系統(tǒng)。 ？建議不存！這樣做確實(shí)可以提高查詢(xún)效率，但在一個(gè)有很多表，并且關(guān)聯(lián)表多的情況下，很難保持?jǐn)?shù)據(jù)的一致性！數(shù)據(jù)庫(kù)結(jié)構(gòu)也比較糟糕。而且不存，也不會(huì)使效率十分低下。 ？個(gè)人認(rèn)為這點(diǎn)很重要，當(dāng)需要修改時(shí)，應(yīng)該先去修改模型，然后同步物理數(shù)據(jù)庫(kù)，尤其是團(tuán)隊(duì)開(kāi)發(fā)，否則要多做更多的事情來(lái)搞定，也可能會(huì)引入更多的錯(cuò)誤。
語(yǔ)文相關(guān)推薦
鄂ICP備17016276號(hào)-1