【文章內(nèi)容簡介】 仔細(xì)選擇數(shù)字類型 在 SQL 中使用 smallint 和 tinyint 類型要特別小心，比如，假如你想看看月銷售總額，你的總額字段類型是 smallint，那么，如果總額超過了 ,767你就不能進(jìn)行計算操作了。 刪除標(biāo)記 在表中包含一個 刪除標(biāo)記 字段，這樣就可以把行標(biāo)記為刪除。在關(guān)系數(shù)據(jù)庫里不要單獨刪除某一行；最好 采用清除數(shù)據(jù)程序而且要仔細(xì)維護(hù)索引整體性。 避免使用觸發(fā)器觸發(fā)器的功能通?？梢杂闷渌绞綄崿F(xiàn)。在調(diào)試程序時觸發(fā)器可能成為干擾。假如你確實需要采用觸發(fā)器，你最好集中對它文檔化。 包含版本機(jī)制 建議你在數(shù)據(jù)庫中引入版本控制機(jī)制來確定使用中的數(shù)據(jù)庫的版本。無論如何你都要實現(xiàn)這一要求。時間一長，用戶的需求總是會改變的。最終可能會要求修改數(shù)據(jù)庫結(jié)構(gòu)。雖然你可以通過檢查新字段或者索引來確定數(shù)據(jù)庫結(jié)構(gòu)的版本，但我發(fā)現(xiàn)把版本信息直接存放到數(shù)據(jù)庫中不更為方便嗎 ?。 給文本字段留足余量 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ī)模的增長了。身份證的號碼從 15位變成 18 位就是最好和最慘痛的例子。 列 [字段 ]命名技巧 我們發(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 在沒有這些前綴的情況下則寫成這個樣子 (用別名來區(qū)分 )： Select*From Customer,Order Where =MYNAME； and = and =1 第 1個 SQL語句沒少鍵入多少字符。但如果查詢涉及到 5個表乃至更多的列 [字段 ]你就知道這個技巧多有用了。 第 3部分 選擇鍵和索引 數(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)從而確定出性能和正確輸出之間的最佳條件。 使用系統(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)時，找到邏輯缺陷很容易。 分解字段用于索引 為了分離命名字段和包含字段以支持用戶定義的報表，請考慮分解其他字段 (甚至主鍵 )為其組成要素以便用戶可以對其進(jìn)行索引。索 引將加快 SQL和報表生成器腳本的執(zhí)行速度。比方說，我通常在必須使用 SQL LIKE 表達(dá)式的情況下創(chuàng)建報表，因為 case number 字段無法分解為 year、 serial number、 case type 和 defendant code 等要素。性能也會變壞。假如年度和類型字段可以分解為索引字段那么這些報表運行起來就會快多了。 鍵設(shè)計 4原則 *為關(guān)聯(lián)字段創(chuàng)建外鍵。 *所有的鍵都必須唯一。 *避免使用復(fù)合鍵。 *外鍵總是關(guān)聯(lián)唯一的鍵字段。 別忘了索引 索引是從數(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 字段，不要 索引大型字段 (有很多字符 )，這樣作會讓索引占用太多的存儲空間。 不要索引常用的小型表 不要為小型數(shù)據(jù)表設(shè)置任何鍵，假如它們經(jīng)常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護(hù)可能比掃描表空間消耗更多的時間。 不要把社會保障號碼 (SSN)或身份證號碼 (ID)選作鍵 永遠(yuǎn)都不要使用 SSN 或 ID 作為數(shù)據(jù)庫的鍵。除了隱私原因以外，須知政府越來越趨向于不準(zhǔn)許把 SSN 或 ID 用作除收入相關(guān)以外的其他目的， SSN 或 ID需要手工輸入。永遠(yuǎn)不要使用手工輸入的鍵作為主鍵，因為一旦你輸入錯誤，你唯一能做的就是刪除整個 記錄然后從頭開始。 我在破解他人的程序時候，我看到很多人把 SSN 或 ID 還曾被用做系列號，當(dāng)然盡管這么做是非法的。而且人們也都知道這是非法的，但他們已經(jīng)習(xí)慣了。后來，隨著盜取身份犯罪案件的增加，我現(xiàn)在的同行正痛苦地從一大攤子數(shù)據(jù)中把 SSN或 ID刪除。 不要用用戶的鍵 在確定采用什么字段作為表的鍵的時候，可一定要小心用戶將要編輯的字段。通常的情況下不要選擇用戶可編輯的字段作為鍵。這樣做會迫使你采取以下兩個措施： *在創(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)該盡量避免。 可選鍵 (候選鍵 )有時可做主鍵 記住，查詢數(shù)據(jù)的不是機(jī)器而是人。 假如你