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