數(shù)據(jù)庫設(shè)計規(guī)范化的五個要求-閱讀頁
2024-08-24 07:39本頁面
【正文】 倉 庫除外)?；砗椭虚g表由DBA維護，臨時表由程序員 自己用程序自動維護。 參照完整性：用PK、FK、表級觸發(fā)器來實現(xiàn)。 13. 防止數(shù)據(jù)庫設(shè)計打補丁的方法是“三少原則” (1) 一個數(shù)據(jù)庫中表的個數(shù)越少越好。因為主鍵的作用，一是建主鍵索引，二是做為子表的外鍵，所以組 合主鍵的字段個數(shù)少了，不僅節(jié)省了運行時間，而且節(jié)省了索引存儲空間； (3) 一個表中的字段個數(shù)越少越好。所謂“列變行”，就是將主表中的一部分內(nèi)容拉出去，另外單獨建一個子表。 數(shù)據(jù)庫設(shè)計的實用原則是：在數(shù)據(jù)冗余和處理速度之間找到合適的平衡點。該原則是相對的，不是絕對的。試想：若覆蓋系統(tǒng)同樣的功 能，一百個實體(共一千個屬性) 的ER圖，肯定比二百個實體(共二千個屬性) 的ER圖，要好得多。數(shù)據(jù)集成的步驟是將文件系統(tǒng)集成 為應(yīng)用數(shù)據(jù)庫，將應(yīng)用數(shù)據(jù)庫集成為主題數(shù)據(jù)庫，將主題數(shù)據(jù)庫集成為全局綜合數(shù)據(jù)庫。 提倡“三少”原則的目的，是防止讀者利用打補丁技術(shù)，不斷地對數(shù)據(jù)庫進行增刪改，使企業(yè)數(shù)據(jù)庫變成了隨意 設(shè)計數(shù)據(jù)庫表的“垃圾堆”，或數(shù)據(jù)庫表的“大雜院”，最后造成數(shù)據(jù)庫中的基本表、代碼表、中間表、臨時表 雜亂無章，不計其數(shù)，導(dǎo)致企事業(yè)單位的信息系統(tǒng)無法維護而癱瘓。“三少”原則是少而精的 原則，它要求有較高的數(shù)據(jù)庫設(shè)計技巧與藝術(shù)，不是任何人都能做到的，因為該原則是杜絕用“打補丁方法” 設(shè)計數(shù)據(jù)庫的理論依據(jù)。 (2) 當(dāng)計算非常復(fù)雜、而且記錄條數(shù)非常巨大時(例如一千萬條)，復(fù)雜計算要先在數(shù)據(jù)庫外面，以文件系統(tǒng)方 式用C++語言計算處理完成之后，最后才入庫追加到表中去。 (3) 發(fā)現(xiàn)某個表的記錄太多，例如超過一千萬條，則要對該表進行水平分割。若發(fā)現(xiàn)某個表的字段太多，例如超過八十個，則 垂直分割該表，將原來的一個表分解為兩個表。 (5) 在使用面向數(shù)據(jù)的SQL語言進行程序設(shè)計時，盡量采取優(yōu)化算法。 上述十四個技巧，是許多人在大量的數(shù)據(jù)庫分析與設(shè)計實踐中，逐步總結(jié)出來的。并逐步做到：在應(yīng)用中發(fā)展，在發(fā)展中應(yīng)用。 我前幾個月訂購了一本人郵圖靈出版的《MySQL 5 權(quán)威指南》第三版中文版，買這本書只是因為有人送我ChinaPub的優(yōu)惠券，我就順手買本MySQL的書，用來管理JavaEye服務(wù)器的時候備查的。但是當(dāng)我隨手翻到第8章第5節(jié)第138頁介紹什么是三大范式的時候，我終于知道我錯了。對于我這個不是計算機科班出身的人來說，到現(xiàn)在才知道什么是三大范式不算可恥。 第三范式： 與主鍵沒有直接關(guān)系的數(shù)據(jù)列必須消除(消除的辦法就是再創(chuàng)建一個表來存放他們)這三大范式就像給ORM的人如何設(shè)計數(shù)據(jù)庫寫的指南： 引用第一范式： 每個持久對象映射一張表 每個持久對象必須有一個主鍵 第二范式： 持久對象要有內(nèi)聚性，冗余的內(nèi)容拿出去，單獨創(chuàng)建持久對象 持久對象之間的關(guān)系用外鍵關(guān)聯(lián) 第三范式： 持久對象要有內(nèi)聚性，無關(guān)的內(nèi)容拿出去，單獨創(chuàng)建持久對象關(guān)系模型和對象模型是不是在存儲概念上一致，就不用多說廢話了。 所以結(jié)論就是這樣： 關(guān)系模型和對象模型存在概念上的阻抗不匹配，但是在關(guān)系數(shù)據(jù)庫的存儲模型上是一致的，無論你從關(guān)系模型的三大范式理論出發(fā)，還是從對象模型的ORM理論出發(fā)，最終一定會得到一致的數(shù)據(jù)庫表設(shè)計。符合三大范式就意味著數(shù)據(jù)庫表會拆分的很細(xì)，表間關(guān)聯(lián)很多，統(tǒng)計分析查詢就不可避免的導(dǎo)致n張表的聯(lián)合查詢，在沒有有效的應(yīng)用層緩存的情況下，這種查詢無可避免的性能低下。 但是我們現(xiàn)在不一樣了，有了良好的ORM框架和應(yīng)用層的對象緩存機制，我們可以做到：讓比較簡單的查詢根本不打擾數(shù)據(jù)庫，讓比較復(fù)雜的查詢盡量少的掃描表記錄，其最終達(dá)到的效果在OLTP類型的應(yīng)用上面效果遠(yuǎn)遠(yuǎn)超過傳統(tǒng)的方式。根據(jù)對數(shù)據(jù)庫和Memcached Server的統(tǒng)計數(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的。所以良好的遵循三大范式，利用好ORM和對象緩存，可以取得非常棒的應(yīng)用性能，還可以讓你的數(shù)據(jù)庫更加輕松。+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++前提聲明，個人觀點： 沒有最好的，只有最合適的。 設(shè)計總是伴隨者“妥協(xié)”的。 大家都提出自己的經(jīng)驗、思路、教訓(xùn)等等，讓參與討論的人根據(jù)自己的條件（這個我們無法完全為他人設(shè)想），有所取舍的得到“我所正需要的”。因為這樣會降低索引的效率，聯(lián)合主鍵一般都要用到至少一個業(yè)務(wù)字段，往往是字符串型的，而且理論上多字段的索引比單字段的索引要慢些。 在實際的設(shè)計中，我盡量避免使用聯(lián)合主鍵，有些時候“不得不”使用聯(lián)合主鍵。而且更容易避開“聯(lián)合主鍵”，而且可以使用索引效率高的字段類型，比如int、long、number。（矛盾無處不在，前面剛說完可以提高效率，這里馬上又降低效率）。 個人使用實際狀況，總體來說“邏輯主鍵”比“業(yè)務(wù)主鍵”執(zhí)行效率低，但不會低到無法滿足需求。 對于分析型數(shù)據(jù)庫，如數(shù)據(jù)倉庫，千萬不要這樣做。這個問題其實不是數(shù)據(jù)庫設(shè)計的問題了，在數(shù)據(jù)庫設(shè)計中，多對多關(guān)系也僅僅存在于邏輯模型（ER）階段，物理模型不在有多對多關(guān)系，實際數(shù)據(jù)庫中也不會有“多對多”關(guān)系。 個人實際使用中，設(shè)計時基本不考慮多對多關(guān)系，但編碼時總會有小組成員使用一些多對多關(guān)系，自己建立多對多的ORM，使自己編碼方便些，用在數(shù)據(jù)量小的地方，影響不大。 ？我習(xí)慣在設(shè)計時給每個表設(shè)一個state字段，取值0或1，默認(rèn)值為1，具體業(yè)務(wù)意義或操作上的意義可以自定義。在數(shù)據(jù)遷移（如轉(zhuǎn)入分析用的數(shù)據(jù)庫）時也可能會發(fā)揮作用。 ？建議不存！這樣做確實可以提高查詢效率，但在一個有很多表，并且關(guān)聯(lián)表多的情況下，很難保持?jǐn)?shù)據(jù)的一致性！數(shù)據(jù)庫結(jié)構(gòu)也比較糟糕。 ？個人認(rèn)為這點很重要，當(dāng)需要修改時，應(yīng)該先去修改模型，然后同步物理數(shù)據(jù)庫，尤其是團隊開發(fā)，否則要多做更多的事情來搞定，也可能會引入更
語文相關(guān)推薦
鄂ICP備17016276號-1