數(shù)據(jù)庫設(shè)計規(guī)范化的五個要求(文件)
【正文】 “三多”原則肯定是錯誤的。集成的程度越高，數(shù)據(jù) 共享性就越強，信息孤島現(xiàn)象就越少，整個企業(yè)信息系統(tǒng)的全局E—R圖中實體的個數(shù)、主鍵的個數(shù)、屬性的個數(shù) 就會越少。 14. 提高數(shù)據(jù)庫運行效率的辦法 在給定的系統(tǒng)硬件和系統(tǒng)軟件條件下，提高數(shù)據(jù)庫系統(tǒng)的運行效率的辦法是： (1) 在數(shù)據(jù)庫物理設(shè)計時，降低范式，增加冗余, 少用觸發(fā)器, 多用存儲過程。水平分割的做法是，以該表主鍵 PK的某個值為界線，將該表的記錄水平分割為兩個表。 總之，要提高數(shù)據(jù)庫的運行效率，必須從數(shù)據(jù)庫系統(tǒng)級優(yōu)化、數(shù)據(jù)庫設(shè)計級優(yōu)化、程序?qū)崿F(xiàn)級優(yōu)化，這三 個層次上同時下功夫。 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++在過去的很多年，我以為關(guān)系模型就是傳統(tǒng)的企業(yè)應(yīng)用當(dāng)中DBA設(shè)計的那些無數(shù)冗余字段，多個模型合并到一個表里面的數(shù)據(jù)庫設(shè)計方式，這種數(shù)據(jù)庫設(shè)計非常適合復(fù)雜的OLAP類型的查詢，他可以有效的消除多表聯(lián)合查詢，而我們大家都知道，大表的復(fù)雜關(guān)聯(lián)查詢是性能殺手，一旦無法有效利用索引，導(dǎo)致了全表掃描，等待你的只有數(shù)據(jù)庫服務(wù)器硬盤燈的狂閃不止，和無數(shù)進程阻塞在IO WAIT狀態(tài)的無奈。 從138頁到142頁，作者深入淺出舉例說明了三大范式，我被震了，就這幾頁讓我覺得買這本書值了。 說關(guān)系模型和對象模型“阻抗不匹配”，當(dāng)然是有不匹配的地方，比方說對象模型當(dāng)中特有的“繼承”，“組合”，“聚合”，“依賴”的概念在關(guān)系模型當(dāng)中是不存在的，但是這種模型的“阻抗不匹配”最終在存儲模型是還是能夠統(tǒng)一起來的，這就是ORM的作用： 對象的繼承關(guān)系可以表達為三種不同的關(guān)系存儲模型：整個繼承數(shù)一張表；每個繼承層次一張表；每個對象一張表 對象的組合和聚合可以用主外鍵關(guān)聯(lián)的表來存儲，它可以表達1:n，n:1和n:m的關(guān)系 對象的依賴關(guān)系和存儲無關(guān)，所以不需要ORM做什么。這使得程序員寧肯違背三大范式，而選擇查詢性能優(yōu)先的數(shù)據(jù)庫設(shè)計。 為了加深大家印象，再給大家一個數(shù)據(jù)，目前JavaEye的Web服務(wù)器CPU負載在4060%左右，而JavaEye的數(shù)據(jù)庫服務(wù)器CPU負載只有20%30%，IO WAIT幾乎沒有。 對不同的視角，所謂的“最合適”也是不同的。 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 以下是針對事務(wù)型數(shù)據(jù)庫： ？個人傾向于少采用聯(lián)合主鍵。 （邏輯主鍵）還是有意義的字段（業(yè)務(wù)主鍵）？個人傾向于“邏輯主鍵”，理由是這樣設(shè)計出的數(shù)據(jù)庫模型結(jié)構(gòu)清晰、關(guān)系脈絡(luò)清楚，往往更符合“第三范式”（雖然不是故意的，呵呵）?！皹I(yè)務(wù)主鍵”可以提升查詢編碼的簡潔度和效率。 ？個人傾向于少使用多對多關(guān)系。大數(shù)據(jù)量，則“禁止使用”。 ？沒辦法，我總是設(shè)計不出“完美”的數(shù)據(jù)表，給每個表加幾個備用字段（我一般用字符串型，隨你）可以應(yīng)付“不時之需”，尤其是需要長期維護的、業(yè)務(wù)可能有臨時性變動的系統(tǒng)。而且不存，也不會使效率十分低下?？梢宰鳛橐粋€狀態(tài)控制字段，如查詢、更新、刪除條件，單據(jù)是否有效（業(yè)務(wù)單據(jù)對應(yīng)的表會有業(yè)務(wù)意義上的“有/無效”或“狀態(tài)”字段，這種情況下，我還是會再加一個state字段），甚至僅僅是控制一條數(shù)據(jù)是否“有效”（有效的意義你自己定）。這是使用ORM時的問題，比如使用Hibernate，多對多關(guān)系有時會使編碼看起來靈活一些，代價是效率的明顯降低。采用“邏輯主鍵”比采用“業(yè)務(wù)主鍵”更利于數(shù)據(jù)庫模型的結(jié)構(gòu)、關(guān)系清晰，也更便于維護。缺點是用無意義的字段建立表間的關(guān)系，使跨表查詢增多，效率下降?？瓷先ニ坪跻膊荒敲辞逅?請不要在討論中試圖證明個人的觀點是“最好的”。 最后，我的結(jié)論就是對象模型和關(guān)系模型在數(shù)據(jù)庫存儲上不存在阻抗不匹配，面向?qū)ο蟮某绦蛟O(shè)計和面向數(shù)據(jù)庫的程序設(shè)計應(yīng)該是一致的，而不應(yīng)該是對立和沖突的，請不要把面向?qū)ο蠛兔嫦驍?shù)據(jù)庫對立起來，不是他們對立，而是你不了解什么才是真正良好的設(shè)計。 以JavaEye網(wǎng)站為例：JavaEye使用了Rails的ActiveRecord ORM，表設(shè)計符合三大范式，所有頁面都是動態(tài)頁面，要對數(shù)據(jù)庫發(fā)送大量查詢，很多Web頁面至少要向數(shù)據(jù)庫發(fā)送50條以上的SQL語句。 這里值得我們反思的一個問題是：為什么傳統(tǒng)的數(shù)據(jù)庫應(yīng)用人們這樣漠視和違反三大范式？在很多所謂的金融、電信等超級大項目當(dāng)中，連主鍵都沒有的表比比皆是，一張表上百個字段，字段之間沒有什么邏輯關(guān)系的情況比比皆是？ 我想答案在于：傳統(tǒng)的數(shù)據(jù)庫應(yīng)用軟件開發(fā)，程序員很難從符合三大范式的數(shù)據(jù)模型當(dāng)中獲得有效的查詢性能。我震驚的只是三大范式和我們現(xiàn)在遵循ORM的原則去設(shè)計數(shù)據(jù)庫的方式如出一轍！我簡單摘要書中內(nèi)容如下： 引用第一范式： 內(nèi)容相似的數(shù)據(jù)列必須消除(消除的辦法就是再創(chuàng)建一個數(shù)據(jù)表來存放他們，建立關(guān)聯(lián)關(guān)系) 必須為每一組相關(guān)數(shù)據(jù)分別創(chuàng)建一個表 每條數(shù)據(jù)記錄必須用一個主鍵來標示 第二范式： 只要數(shù)據(jù)列里面的內(nèi)容出現(xiàn)重復(fù)，就意味著應(yīng)該把表拆分為多個表 拆分形成的表必須用外鍵關(guān)聯(lián)起來。其實這本書內(nèi)容很一般，他說的東西我都知道了，所以這本書我拿過來隨手翻了翻就感覺到買的不值得。對于這些經(jīng)驗的運用，讀者 不能生幫硬套，死記硬背，而要消化理解，實事求是，靈活掌握。 (4) 對數(shù)據(jù)庫管理系統(tǒng)DBMS進行系統(tǒng)優(yōu)化，即優(yōu)化各種系統(tǒng)參數(shù)，如緩沖區(qū)個數(shù)。這是電信計費系統(tǒng)設(shè)計的經(jīng)驗。 “三多”原則任何人都可以做到，該原則是“打補丁方法”設(shè)計數(shù)據(jù)庫的歪理學(xué)說。 提倡“三少”原則，是叫讀者學(xué)會利用數(shù)據(jù)庫設(shè)計技術(shù)進行系統(tǒng)的數(shù)據(jù)集成?！叭佟笔且粋€整體概念，綜合觀點， 不能孤立某一個原則。只有字段的個數(shù)少了，才能說明在系統(tǒng)中不存在數(shù)據(jù)重復(fù)，且很少有數(shù)據(jù)冗 余，更重要的是督促讀者學(xué)會“列變行”，這樣就防止了將子表中的字段拉入到主表中去，在主表中留下許 多空余的字段。 用戶定義完整性：它是一些業(yè)務(wù)規(guī)則，用存儲過程和觸發(fā)器來實現(xiàn)。臨時表是程序員個人設(shè)計的，存放臨時記錄，為個人所用。這些系統(tǒng)的基本表完 成物理設(shè)計之后，立即在基本表上建立第一層視圖，這層視圖的個數(shù)和結(jié)構(gòu)，與基本表的個數(shù)和結(jié)構(gòu)是完全相同。為了進行復(fù)雜處理、 提高運算速度和節(jié)省存儲空
語文相關(guān)推薦
鄂ICP備17016276號-1