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