【正文】 ？建議不存！這樣做確實可以提高查詢效率，但在一個有很多表，并且關(guān)聯(lián)表多的情況下，很難保持?jǐn)?shù)據(jù)的一致性！數(shù)據(jù)庫結(jié)構(gòu)也比較糟糕。這個問題其實不是數(shù)據(jù)庫設(shè)計的問題了，在數(shù)據(jù)庫設(shè)計中，多對多關(guān)系也僅僅存在于邏輯模型（ER）階段，物理模型不在有多對多關(guān)系，實際數(shù)據(jù)庫中也不會有“多對多”關(guān)系。而且更容易避開“聯(lián)合主鍵”，而且可以使用索引效率高的字段類型，比如int、long、number。 設(shè)計總是伴隨者“妥協(xié)”的。 但是我們現(xiàn)在不一樣了，有了良好的ORM框架和應(yīng)用層的對象緩存機制，我們可以做到：讓比較簡單的查詢根本不打擾數(shù)據(jù)庫，讓比較復(fù)雜的查詢盡量少的掃描表記錄，其最終達(dá)到的效果在OLTP類型的應(yīng)用上面效果遠(yuǎn)遠(yuǎn)超過傳統(tǒng)的方式。對于我這個不是計算機科班出身的人來說，到現(xiàn)在才知道什么是三大范式不算可恥。 　　上述十四個技巧，是許多人在大量的數(shù)據(jù)庫分析與設(shè)計實踐中，逐步總結(jié)出來的。 　　 (2) 當(dāng)計算非常復(fù)雜、而且記錄條數(shù)非常巨大時(例如一千萬條)，復(fù)雜計算要先在數(shù)據(jù)庫外面，以文件系統(tǒng)方 　　　　式用C++語言計算處理完成之后，最后才入庫追加到表中去。試想：若覆蓋系統(tǒng)同樣的功 　　能，一百個實體(共一千個屬性) 的ER圖，肯定比二百個實體(共二千個屬性) 的ER圖，要好得多。因為主鍵的作用，一是建主鍵索引，二是做為子表的外鍵，所以組 　　　　合主鍵的字段個數(shù)少了，不僅節(jié)省了運行時間，而且節(jié)省了索引存儲空間； 　　 (3) 一個表中的字段個數(shù)越少越好。請讀者想想：這是為什么？ 11. 中間表、報表和臨時表 　　中間表是存放統(tǒng)計數(shù)據(jù)的表，它是為數(shù)據(jù)倉庫、輸出報表或查詢結(jié)果而設(shè)計的，有時它沒有主鍵與外鍵(數(shù)據(jù)倉 　　庫除外)。視圖是供程序員使用數(shù)據(jù)庫的 　　一個窗口，是基表數(shù)據(jù)綜合的一種形式, 是數(shù)據(jù)處理的一種方法，是用戶數(shù)據(jù)保密的一種手段。冗余的目的是為了提高處理速度。 7. 主鍵PK的取值方法 　　 PK是供程序員使用的表間連接工具，可以是一無物理意義的數(shù)字串, 由程序自動加1來實現(xiàn)。消除的辦法是，在兩者之間增加第三個實體。“金額”這樣的列被稱為“計算列”，而“單價”和 　　“數(shù)量”這樣的列被稱為“數(shù)據(jù)列”。 　　理解基本表的性質(zhì)后，在設(shè)計數(shù)據(jù)庫時，就能將基本表與中間表、臨時表區(qū)分開來。 3. 基本表的性質(zhì) 　　基本表與中間表、臨時表不同，因為它具有如下四個特性： 　　 (1) 原子性。 　　〖例1〗：一份員工履歷資料，在人力資源信息系統(tǒng)中，就對應(yīng)三個基本表：員工基本情況表、社會關(guān)系表、工作簡歷表。四個范式確保了不會出現(xiàn)異常，但也可能由此導(dǎo)致過于純潔的設(shè)計，使得表結(jié)構(gòu)難于使用，所以在設(shè)計時需要進行綜合判斷，但首先確保符合四個范式，然后再進行精化修正是剛剛進入數(shù)據(jù)庫設(shè)計領(lǐng)域時可以采用的最好辦法。并且，我認(rèn)為數(shù)據(jù)庫中的表是用來持久化一個對象實例在特定時間及特定條件下的狀態(tài)的，只是一個存儲介質(zhì)，所以，表和表之間也不應(yīng)用強關(guān)聯(lián)來表述業(yè)務(wù)(數(shù)據(jù)間的一致性)，這一職責(zé)應(yīng)由系統(tǒng)的邏輯層來保證，這種方式也確保了系統(tǒng)對于不正確數(shù)據(jù)(臟數(shù)據(jù))的兼容性。在確定關(guān)鍵字時，應(yīng)保證關(guān)鍵字不會參與業(yè)務(wù)且不會出現(xiàn)更新異常，這時，最優(yōu)解決方案為采用一個自增數(shù)值型屬性或一個隨機字符串作為表的關(guān)鍵字。而且，數(shù)據(jù)庫規(guī)范往往沒有技術(shù)方面的嚴(yán)格限制，主要依靠數(shù)據(jù)庫管理員日常工作經(jīng)驗的累積。　　如當(dāng)后續(xù)有圖書出版時，則需要為每次出版的圖書增加作者信息，這無疑會增加額外的存儲空間，也會增加記錄的長度。如此數(shù)據(jù)庫管理員無論是在日常管理還是對象引用的時候，都能夠在最短的時間內(nèi)找到自己所需要的對象。如筆者在數(shù)據(jù)庫設(shè)計時，喜歡跟前臺應(yīng)用程序協(xié)商，確定合理的命名規(guī)范。如此的話，原來來行號為30的紀(jì)錄現(xiàn)在行號變?yōu)榱?，就可以在第一行中顯示。但是，行號用戶就可以維護。也就是說，盡量將重復(fù)的值放置到一張獨立的表中進行管理?？墒沁@么處理的話，會把原先采購訂單上采購員的名字也改變了。如我們也可以這么設(shè)計，把客戶信息、聯(lián)系人都放入同一張表中。所以，在產(chǎn)品基本信息表產(chǎn)品開發(fā)者這個字段中，有時候可能需要填入多個開發(fā)者的名字。以避免空字段的產(chǎn)生。　　一是通過設(shè)置默認(rèn)值的形式，來避免空字段的產(chǎn)生。當(dāng)然這是兩個泛泛而談的指標(biāo)。為了達(dá)到數(shù)據(jù)庫設(shè)計規(guī)范化的要求，一般來說，需要符合以下五個要求。如在一個人事管理系統(tǒng)中，有時候身份證號碼字段可能允許為空?！　《侨粢粡埍碇校试S為空的列比較多，接近表全部列數(shù)的三分之一?！　∪邕M銷存管理中，還需要對客戶的聯(lián)系人進行管理。為了解決多個聯(lián)系人的問題，可以設(shè)置第一聯(lián)系人、第一聯(lián)系人電話、第二聯(lián)系人、第二聯(lián)系人電話等等。因為采購單上客戶采購員信息在數(shù)據(jù)庫中存儲的不是采購員的名字，而只是采購員對應(yīng)的一個編號。然后通過視圖或者其他手段把這些獨立的表聯(lián)系起來。如在銷售訂單的行中，用戶可以通過調(diào)整行號的大小來對訂單行進行排序。這是在實際應(yīng)用程序設(shè)計中對ID列的一個有效補充。筆者最常用的是根據(jù)前臺應(yīng)用程序的模塊來定義后臺數(shù)據(jù)庫對象前綴名?！　∫笪澹罕M量只存儲單一實體類型的數(shù)據(jù)　　這里將的實體類型跟數(shù)據(jù)類型不是一回事，要注意區(qū)分。而且若作者的情況有所改變，如住址改變了以后，則還需要去更改每本書的記錄。++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++數(shù)據(jù)表的設(shè)計原則:　　(1)不應(yīng)針對整個系統(tǒng)進行數(shù)據(jù)庫設(shè)計，而應(yīng)該根據(jù)系統(tǒng)架構(gòu)中的組件劃分，針對每個組件所處理的業(yè)務(wù)進行組件單元的數(shù)據(jù)庫設(shè)計?！　?4)由于第一點所述的領(lǐng)域模型驅(qū)動的方式設(shè)計數(shù)據(jù)庫表結(jié)構(gòu)，領(lǐng)域模型中的每一個對象只有一項職責(zé)，所以對象中的數(shù)據(jù)項不存在傳遞依賴，所以，這種思路的數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計從一開始即滿足第三范式：一個表應(yīng)滿足第二范式，且屬性間不存在傳遞依賴。當(dāng)然，從整個系統(tǒng)的角度來說我們還是要盡最大努力確保系統(tǒng)不會產(chǎn)生臟數(shù)據(jù)，單從另一個角度來說，臟數(shù)據(jù)的產(chǎn)生在一定程度上也是不可避免的，我們也要保證系統(tǒng)對這種情況的容錯性?！　?11)設(shè)計出的表要具有較好的使用性，主要體現(xiàn)在查詢時是否需要關(guān)聯(lián)多張表且還需使用復(fù)雜的SQL技巧。 　　　　　　基本表中的字段是不可再分解的。 4. 范式標(biāo)準(zhǔn) 　　基本表及其字段之間的關(guān)系, 應(yīng)盡量滿足第三范式。 　　表1 商品表的表結(jié)構(gòu) 　　商品名稱 商品型號 單價 數(shù)量 金額 　　電視