|
21. 避免使用觸發(fā)器 觸發(fā)器的功能通?？梢杂闷渌绞綄崿F(xiàn)。在調(diào)試程序時觸發(fā)器可能成為干擾。假如你確實需要采用觸發(fā)器，你最好集中對它文檔化。 22. 包含版本機(jī)制 建議你在數(shù)據(jù)庫中引入版本控制機(jī)制來確定使用中的數(shù)據(jù)庫的版本。無論如何你都要實現(xiàn)這一要求。時間一長，用戶的需求總是會改變的。最終可能會要求修改數(shù)據(jù)庫結(jié)構(gòu)。雖然你可以通過檢查新字段或者索引來確定數(shù)據(jù)庫結(jié)構(gòu)的版本，但我發(fā)現(xiàn)把版本信息直接存放到數(shù)據(jù)庫中不更為方便嗎？。 23. 給文本字段留足余量 ID 類型的文本字段，比如客戶ID 或定單號等等都應(yīng)該設(shè)置得比一般想象更大，因為時間不長你多半就會因為要添加額外的字符而難堪不已。比方說，假設(shè)你的客戶ID 為10 位數(shù)長。那你應(yīng)該把數(shù)據(jù)庫表字段的長度設(shè)為12 或者13 個字符長。這算浪費空間嗎？是有一點，但也沒你想象的那么多：一個字段加長3 個字符在有1 百萬條記錄，再加上一點索引的情況下才不過讓整個數(shù)據(jù)庫多占據(jù)3MB 的空間。但這額外占據(jù)的空間卻無需將來重構(gòu)整個數(shù)據(jù)庫就可以實現(xiàn)數(shù)據(jù)庫規(guī)模的增長了。 24. 列命名技巧 我們發(fā)現(xiàn)，假如你給每個表的列名都采用統(tǒng)一的前綴，那么在編寫SQL 表達(dá)式的時候會得到大大的簡化。這樣做也確實有缺點，比如破壞了自動表連接工具的作用，后者把公共列名同某些數(shù)據(jù)庫聯(lián)系起來，不過就連這些工具有時不也連接錯誤嘛。舉個簡單的例子，假設(shè)有兩個表： Customer 和Order。Customer 表的前綴是cu_，所以該表內(nèi)的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前綴是or_，所以子段名是：or_order_id、or_cust_name_id、or_quantity 和or_description 等。 這樣從數(shù)據(jù)庫中選出全部數(shù)據(jù)的SQL 語句可以寫成如下所示： Select * from Customer, Order Where cu_surname = "MYNAME" and cu_name_id = or_cust_name_id and or_quantity = 1; 在沒有這些前綴的情況下則寫成這個樣子： Select * from Customer, Order Where Customer.surname = "MYNAME" and Customer.name_id = Order.cust_name_id and Order.quantity = 1 第1 個SQL 語句沒少鍵入多少字符。但如果查詢涉及到5 個表乃至更多的列你就知道這個技巧多有用了。 第3 部分— 選擇鍵和索引 1. 數(shù)據(jù)采掘要預(yù)先計劃 我所在的市場部門一度要處理8 萬多份聯(lián)系方式，同時填寫每個客戶的必要數(shù)據(jù)（這絕對不是小活）。我從中還要確定出一組客戶作為市場目標(biāo)。當(dāng)我從最開始設(shè)計表和字段的時候，我試圖不在主索引里增加太多的字段以便加快數(shù)據(jù)庫的運行速度。然后我意識到特定的組查詢和信息采掘既不準(zhǔn)確速度也不快。結(jié)果只好在主索引中重建而且合并了數(shù)據(jù)字段。我發(fā)現(xiàn)有一個指示計劃相當(dāng)關(guān)鍵——當(dāng)我想創(chuàng)建系統(tǒng)類型查找時為什么要采用號碼作為主索引字段呢？我可以用傳真號碼進(jìn)行檢索，但是它幾乎就象系統(tǒng)類型一樣對我來說并不重要。采用后者作為主字段，數(shù)據(jù)庫更新后重新索引和檢索就快多了。 可操作數(shù)據(jù)倉庫（ODS）和數(shù)據(jù)倉庫（DW）這兩種環(huán)境下的數(shù)據(jù)索引是有差別的。在DW 環(huán)境下，你要考慮銷售部門是如何組織銷售活動的。他們并不是數(shù)據(jù)庫管理員，但是他們確定表內(nèi)的鍵信息。這里設(shè)計人員或者數(shù)據(jù)庫工作人員應(yīng)該分析數(shù)據(jù)庫結(jié)構(gòu)從而確定出性能和正確輸出之間的最佳條件。 2. 使用系統(tǒng)生成的主鍵 這一天類同技巧1，但我覺得有必要在這里重復(fù)提醒大家。假如你總是在設(shè)計數(shù)據(jù)庫的時候采用系統(tǒng)生成的鍵作為主鍵，那么你實際控制了數(shù)據(jù)庫的索引完整性。這樣，數(shù)據(jù)庫和非人工機(jī)制就有效地控制了對存儲數(shù)據(jù)中每一行的訪問。 采用系統(tǒng)生成鍵作為主鍵還有一個優(yōu)點：當(dāng)你擁有一致的鍵結(jié)構(gòu)時，找到邏輯缺陷很容易。 3. 分解字段用于索引 為了分離命名字段和包含字段以支持用戶定義的報表，請考慮分解其他字段（甚至主鍵）為其組成要素以便用戶可以對其進(jìn)行索引。索引將加快SQL 和報表生成器腳本的執(zhí)行速度。比方說，我通常在必須使用SQL LIKE 表達(dá)式的情況下創(chuàng)建報表，因為case number 字段無法分解為year、serial number、case type 和defendant code 等要素。性能也會變壞。假如年度和類型字段可以分解為索引字段那么這些報表運行起來就會快多了。 4. 鍵設(shè)計4 原則 · 為關(guān)聯(lián)字段創(chuàng)建外鍵。 · 所有的鍵都必須唯一。 · 避免使用復(fù)合鍵。 · 外鍵總是關(guān)聯(lián)唯一的鍵字段。 5. 別忘了索引 索引是從數(shù)據(jù)庫中獲取數(shù)據(jù)的最高效方式之一。95%的數(shù)據(jù)庫性能問題都可以采用索引技術(shù)得到解決。作為一條規(guī)則，我通常對邏輯主鍵使用唯一的成組索引，對系統(tǒng)鍵（作為存儲過程）采用唯一的非成組索引，對任何外鍵列采用非成組索引。不過，索引就象是鹽，太多了菜就篌了。你得考慮數(shù)據(jù)庫的空間有多大，表如何進(jìn)行訪問，還有這些訪問是否主要用作讀寫。 大多數(shù)數(shù)據(jù)庫都索引自動創(chuàng)建的主鍵字段，但是可別忘了索引外鍵，它們也是經(jīng)常使用的鍵，比如運行查詢顯示主表和所有關(guān)聯(lián)表的某條記錄就用得上。還有，不要索引memo/note 字段，不要索引大型字段（有很多字符），這樣作會讓索引占用太多的存儲空間。 6. 不要索引常用的小型表 不要為小型數(shù)據(jù)表設(shè)置任何鍵，假如它們經(jīng)常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護(hù)可能比掃描表空間消耗更多的時間。 7. 不要把社會保障號碼（SSN）選作鍵 永遠(yuǎn)都不要使用SSN 作為數(shù)據(jù)庫的鍵。除了隱私原因以外，須知政府越來越趨向于不準(zhǔn)許把SSN 用作除收入相關(guān)以外的其他目的，SSN 需要手工輸入。永遠(yuǎn)不要使用手工輸入的鍵作為主鍵，因為一旦你輸入錯誤，你唯一能做的就是刪除整個記錄然后從頭開始。 上個世紀(jì)70 年代我還在讀大學(xué)的時候，我記得那時SSN 還曾被用做學(xué)號，當(dāng)然盡管這么做是非法的。而且人們也都知道這是非法的，但他們已經(jīng)習(xí)慣了。后來，隨著盜取身份犯罪案件的增加，我現(xiàn)在的大學(xué)校園正痛苦地從一大攤子數(shù)據(jù)中把SSN 刪除。 8. 不要用用戶的鍵 在確定采用什么字段作為表的鍵的時候，可一定要小心用戶將要編輯的字段。通常的情況下不要選擇用戶可編輯的字段作為鍵。這樣做會迫使你采取以下兩個措施： · 在創(chuàng)建記錄之后對用戶編輯字段的行為施加限制。假如你這么做了，你可能會發(fā)現(xiàn)你的應(yīng)用程序在商務(wù)需求突然發(fā)生變化，而用戶需要編輯那些不可編輯的字段時缺乏足夠的靈活性。當(dāng)用戶在輸入數(shù)據(jù)之后直到保存記錄才發(fā)現(xiàn)系統(tǒng)出了問題他們該怎么想？刪除重建？假如記錄不可重建是否讓用戶走開？ · 提出一些檢測和糾正鍵沖突的方法。通常，費點精力也就搞定了，但是從性能上來看這樣做的代價就比較大了。還有，鍵的糾正可能會迫使你突破你的數(shù)據(jù)和商業(yè)/用戶界面層之間的隔離。 所以還是重提一句老話：你的設(shè)計要適應(yīng)用戶而不是讓用戶來適應(yīng)你的設(shè)計。 不讓主鍵具有可更新性的原因是在關(guān)系模式下，主鍵實現(xiàn)了不同表之間的關(guān)聯(lián)。比如，Customer 表有一個主鍵CustomerID，而客戶的定單則存放在另一個表里。Order 表的主鍵可能是OrderNo 或者OrderNo、CustomerID 和日期的組合。不管你選擇哪種鍵設(shè)置，你都需要在Order 表中存放CustomerID 來保證你可以給下定單的用戶找到其定單記錄。 假如你在Customer 表里修改了CustomerID，那么你必須找出Order 表中的所有相關(guān)記錄對其進(jìn)行修改。否則，有些定單就會不屬于任何客戶——數(shù)據(jù)庫的完整性就算完蛋了。 如果索引完整性規(guī)則施加到表一級，那么在不編寫大量代碼和附加刪除記錄的情況下幾乎不可能改變某一條記錄的鍵和數(shù)據(jù)庫內(nèi)所有關(guān)聯(lián)的記錄。而這一過程往往錯誤叢生所以應(yīng)該盡量避免。 9. 可選鍵有時可做主鍵 記住，查詢數(shù)據(jù)的不是機(jī)器而是人。 假如你有可選鍵，你可能進(jìn)一步把它用做主鍵。那樣的話，你就擁有了建立強(qiáng)大索引的能力。這樣可以阻止使用數(shù)據(jù)庫的人不得不連接數(shù)據(jù)庫從而恰當(dāng)?shù)倪^濾數(shù)據(jù)。在嚴(yán)格控制域表的數(shù)據(jù)庫上，這種負(fù)載是比較醒目的。如果可選鍵真正有用，那就是達(dá)到了主鍵的水準(zhǔn)。 我的看法是，假如你有可選鍵，比如國家表內(nèi)的state_code，你不要在現(xiàn)有不能變動的唯一鍵上創(chuàng)建后續(xù)的鍵。你要做的無非是創(chuàng)建毫無價值的數(shù)據(jù)。比如以下的例子： 10. 別忘了外鍵 大多數(shù)數(shù)據(jù)庫索引自動創(chuàng)建的主鍵字段。但別忘了索引外鍵字段，它們在你想查詢主表中的記錄及其關(guān)聯(lián)記錄時每次都會用到。還有，不要索引memo/notes 字段而且不要索引大型文本字段（許多字符），這樣做會讓你的索引占據(jù)大量的數(shù)據(jù)庫空間。 第4 部分— 保證數(shù)據(jù)的完整性 1. 用約束而非商務(wù)規(guī)則強(qiáng)制數(shù)據(jù)完整性 如果你按照商務(wù)規(guī)則來處理需求，那么你應(yīng)當(dāng)檢查商務(wù)層次/用戶界面：如果商務(wù)規(guī)則以后發(fā)生變化，那么只需要進(jìn)行更新即可。 假如需求源于維護(hù)數(shù)據(jù)完整性的需要，那么在數(shù)據(jù)庫層面上需要施加限制條件。 如果你在數(shù)據(jù)層確實采用了約束，你要保證有辦法把更新不能通過約束檢查的原因采用用戶理解的語言通知用戶界面。除非你的字段命名很冗長，否則字段名本身還不夠。 Select count(*) from address, state_ref where address.state_id = state_ref.state_id and state_ref.state_code = ‘TN‘ 我的做法是這樣的： Select count(*) from address where and state_code = ‘TN‘ 如你因為過度使用表的后續(xù)鍵建立這種表的關(guān)聯(lián)，操作負(fù)載真得需要考慮一下了。 只要有可能，請采用數(shù)據(jù)庫系統(tǒng)實現(xiàn)數(shù)據(jù)的完整性。這不但包括通過標(biāo)準(zhǔn)化實現(xiàn)的完整性而且還包括數(shù)據(jù)的功能性。在寫數(shù)據(jù)的時候還可以增加觸發(fā)器來保證數(shù)據(jù)的正確性。不要依賴于商務(wù)層保證數(shù)據(jù)完整性；它不能保證表之間（外鍵）的完整性所以不能強(qiáng)加于其他完整性規(guī)則之上。 2. 分布式數(shù)據(jù)系統(tǒng) 對分布式系統(tǒng)而言，在你決定是否在各個站點復(fù)制所有數(shù)據(jù)還是把數(shù)據(jù)保存在一個地方之前應(yīng)該估計一下未來5 年或者10 年的數(shù)據(jù)量。當(dāng)你把數(shù)據(jù)傳送到其他站點的時候，最好在數(shù)據(jù)庫字段中設(shè)置一些標(biāo)記。在目的站點收到你的數(shù)據(jù)之后更新你的標(biāo)記。為了進(jìn)行這種數(shù)據(jù)傳輸，請寫下你自己的批處理或者調(diào)度程序以特定時間間隔運行而不要讓用戶在每天的工作后傳輸數(shù)據(jù)。本地拷貝你的維護(hù)數(shù)據(jù)，比如計算常數(shù)和利息率等，設(shè)置版本號保證數(shù)據(jù)在每個站點都完全一致。 3. 強(qiáng)制指示完整性 沒有好辦法能在有害數(shù)據(jù)進(jìn)入數(shù)據(jù)庫之后消除它，所以你應(yīng)該在它進(jìn)入數(shù)據(jù)庫之前將其剔除。激活數(shù)據(jù)庫系統(tǒng)的指示完整性特性。這樣可以保持?jǐn)?shù)據(jù)的清潔而能迫使開發(fā)人員投入更多的時間處理錯誤條件。 4. 關(guān)系 如果兩個實體之間存在多對一關(guān)系，而且還有可能轉(zhuǎn)化為多對多關(guān)系，那么你最好一開始就設(shè)置成多對多關(guān)系。從現(xiàn)有的多對一關(guān)系轉(zhuǎn)變?yōu)槎鄬Χ嚓P(guān)系比一開始就是多對多關(guān)系要難得多。 |
|
|
