引用：http://blog.csdn.net/softj/services/trackbacks/497813.aspx
第 3 部分 - 選擇鍵和索引
資料採掘要預先計畫
我所在的某一客戶部門一度要處理 8 萬多份****，同時填寫每個客戶的必要資料（這絕對不是小活）。我從中還要確定出一組客戶作為市場目標。當我從最開始設計表和字段的時候，我試圖不在主索引裡增加太多的字段以便加快資料庫的執行速度。然後我意識到特定的組查詢和資訊採掘既不準確速度也不快。結果只好在主索引中重建而且合併了資料字段。我發現有乙個指示計畫相當關鍵——當我想建立系統型別查詢時為什麼要採用號碼作為主索引欄位呢？我可以用傳真號碼進行檢索，但是它幾乎就象系統型別一樣對我來說並不重要。採用後者作為主欄位，資料庫更新後重新索引和檢索就快多了。
可操作資料倉儲（ods）和資料倉儲（dw）這兩種環境下的資料索引是有差別的。在 dw 環境下，你要考慮銷售部門是如何組織銷售活動的。他們並不是資料庫管理員，但是他們確定表內的鍵資訊。這裡設計人員或者資料庫工作人員應該分析資料庫結構從而確定出效能和正確輸出之間的最佳條件。
使用系統生成的主鍵
這類同技巧 1，但我覺得有必要在這裡重複提醒大家。假如你總是在設計資料庫的時候採用系統生成的鍵作為主鍵，那麼你實際控制了資料庫的索引完整性。這樣，資料庫和非人工機制就有效地控制了對儲存資料中每一行的訪問。
採用系統生成鍵作為主鍵還有乙個優點：當你擁有一致的鍵結構時，找到邏輯缺陷很容易。
分解字段用於索引
為了分離命名字段和包含欄位以支援使用者定義的報表，請考慮分解其他字段（甚至主鍵）為其組成要素以便使用者可以對其進行索引。索引將加快 sql 和報表生成器指令碼的執行速度。比方說，我通常在必須使用 sql like 表示式的情況下建立報表，因為 case number 字段無法分解為 year、serial number、case type 和 defendant code 等要素。效能也會變壞。假如年度和型別字段可以分解為索引字段那麼這些報表執行起來就會快多了。
鍵設計 4 原則
* 為關聯字段建立外來鍵。
* 所有的鍵都必須唯一。
* 避免使用復合鍵。
* 外來鍵總是關聯唯一的鍵字段。
別忘了索引
索引是從資料庫中獲取資料的最高效方式之一。95% 的資料庫效能問題都可以採用索引技術得到解決。作為一條規則，我通常對邏輯主鍵使用唯一的成組索引，對系統鍵（作為儲存過程）採用唯一的非成組索引，對任何外來鍵列[字段]採用非成組索引。不過，索引就象是鹽，太多了菜就鹹了。你得考慮資料庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。
大多數資料庫都索引自動建立的主鍵字段，但是可別忘了索引外來鍵，它們也是經常使用的鍵，比如執行查詢顯示主表和所有關聯表的某條記錄就用得上。還有，不要索引 memo/note 字段，不要索引大型字段（有很多字元），這樣作會讓索引占用太多的儲存空間。
不要索引常用的小型表
不要為小型資料表設定任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃瞄表空間消耗更多的時間。
不要把社會保障號碼（ssn）或身份證號碼（id）選作鍵
永遠都不要使用 ssn 或 id 作為資料庫的鍵。除了隱私原因以外，須知**越來越趨向於不准許把 ssn 或 id 用作除收入相關以外的其他目的，ssn 或 id 需要手工輸入。永遠不要使用手工輸入的鍵作為主鍵，因為一旦你輸入錯誤，你唯一能做的就是刪除整個記錄然後從頭開始。
我在破解他人的程式時候，我看到很多人把 ssn 或 id 還曾被用做系列號，當然儘管這麼做是非法的。而且人們也都知道這是非法的，但他們已經習慣了。後來，隨著盜取身份犯罪案件的增加，我現在的同行正痛苦地從一大攤子資料中把 ssn 或 id 刪除。
不要用使用者的鍵
在確定採用什麼字段作為表的鍵的時候，可一定要小心使用者將要編輯的字段。通常的情況下不要選擇使用者可編輯的字段作為鍵。這樣做會迫使你採取以下兩個措施：
* 在建立記錄之後對使用者編輯欄位的行為施加限制。假如你這麼做了，你可能會發現你的應用程式在商務需求突然發生變化，而使用者需要編輯那些不可編輯的字段時缺乏足夠的靈活性。當使用者在輸入資料之後直到儲存記錄才發現系統出了問題他們該怎麼想？刪除重建？假如記錄不可重建是否讓使用者走開？
* 提出一些檢測和糾正鍵衝突的方法。通常，費點精力也就搞定了，但是從效能上來看這樣做的代價就比較大了。還有，鍵的糾正可能會迫使你突破你的資料和商業/使用者介面層之間的隔離。
所以還是重提一句老話：你的設計要適應使用者而不是讓使用者來適應你的設計。
不讓主鍵具有可更新性的原因是在關係模式下，主鍵實現了不同表之間的關聯。比如，customer 表有乙個主鍵 customerid，而客戶的定單則存放在另乙個表裡。order 表的主鍵可能是 orderno 或者 orderno、customerid 和日期的組合。不管你選擇哪種鍵設定，你都需要在 order 表中存放 customerid 來保證你可以給下定單的使用者找到其定單記錄。
假如你在 customer 表裡修改了 customerid，那麼你必須找出 order 表中的所有相關記錄對其進行修改。否則，有些定單就會不屬於任何客戶——資料庫的完整性就算完蛋了。
如果索引完整性規則施加到表一級，那麼在不編寫大量**和附加刪除記錄的情況下幾乎不可能改變某一條記錄的鍵和資料庫內所有關聯的記錄。而這一過程往往錯誤叢生所以應該盡量避免。
可選鍵(候選鍵)有時可做主鍵
記住，查詢資料的不是機器而是人。
假如你有可選鍵，你可能進一步把它用做主鍵。那樣的話，你就擁有了建立強大索引的能力。這樣可以阻止使用資料庫的人不得不連線資料庫從而恰當的過濾資料。在嚴格控制域表的資料庫上，這種負載是比較醒目的。如果可選鍵真正有用，那就是達到了主鍵的水準。
我的看法是，假如你有可選鍵，比如國家表內的 state_code，你不要在現有不能變動的唯一鍵上建立後續的鍵。你要做的無非是建立毫無價值的資料。如你因為過度使用表的後續鍵[別名]建立這種表的關聯，操作負載真得需要考慮一下了。
別忘了外來鍵
大多數資料庫索引自動建立的主鍵字段。但別忘了索引外來鍵字段，它們在你想查詢主表中的記錄及其關聯記錄時每次都會用到。還有，不要索引 memo/notes 字段而且不要索引大型文字字段（許多字元），這樣做會讓你的索引佔據大量的資料庫空間。
第 4 部分 - 保證資料的完整性
用約束而非商務規則強制資料完整性
如果你按照商務規則來處理需求，那麼你應當檢查商務層次/使用者介面：如果商務規則以後發生變化，那麼只需要進行更新即可。假如需求源於維護資料完整性的需要，那麼在資料庫層面上需要施加限制條件。如果你在資料層確實採用了約束，你要保證有辦法把更新不能通過約束檢查的原因採用使用者理解的語言通知使用者介面。除非你的字段命名很冗長，否則欄位名本身還不夠。
採用給表、列[字段]、觸發器等加注釋的資料庫工具。是的，這有點費事，但從長遠來看，這樣做對開發、支援和跟蹤修改非常有用。
取決於你使用的資料庫系統，可能有一些軟體會給你一些供你很快上手的文件。你可能希望先開始在說，然後獲得越來越多的細節。或者你可能希望週期性的預排，在輸入新資料同時隨著你的進展對每一部分細節化。不管你選擇哪種方式，總要對你的資料庫文件化，或者在資料庫自身的內部或者單獨建立文件。這樣，當你過了一年多時間後再回過頭來做第 2 個版本，你犯錯的機會將大大減少。
使用常用英語（或者其他任何語言）而不要使用編碼
為什麼我們經常採用編碼（比如 9935a 可能是『青島啤酒』的****，4xf788-q 可能是帳目編碼）？理由很多。但是使用者通常都用英語進行思考而不是編碼。工作 5 年的會計或許知道 4xf788-q 是什麼東西，但新來的可就不一定了。在建立下拉列表、列表、報表時最好按照英語名排序。假如你需要編碼，那你可以在編碼旁附上使用者知道的英語。
儲存常用資訊
讓乙個表專門存放一般資料庫資訊非常有用。我常在這個表裡存放資料庫當前版本、最近檢查/修復（對 foxpro）、關聯設計文件的名稱、客戶等資訊。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯絡時，這樣做對非客戶機/伺服器環境特別有用。
測試、測試、反覆測試
建立或者修訂資料庫之後，必須用使用者新輸入的資料測試資料字段。最重要的是，讓使用者進行測試並且同使用者一道保證你選擇的資料型別滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。
檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支援的應用程式原型檢查資料庫。換句話說，針對每一種最終表達資料的原型應用，保證你檢查了資料模型並且檢視如何取出資料。
microsoft visual foxpro 設計技巧
對複雜的 microsoft visual foxpro 資料庫應用程式而言，可以把所有的主表放在乙個資料庫容器檔案裡，然後增加其他資料庫表檔案和裝載同原有資料庫有關的特殊檔案。根據需要用這些檔案連線到主檔案中的主表。比如資料輸入、資料索引、統計分析、向管理層或者**部門提供報表以及各類唯讀查詢等。這一措施簡化了使用者和組許可權的分配，而且有利於應用程式函式（儲存過程）的分組和劃分，從而在程式必須修改的時候易於管理。
資料庫設計經驗談 下
資料庫設計經驗談 下 第 3 部分 選擇鍵和索引 資料採掘要預先計畫 我所在的某一客戶部門一度要處理 8 萬多份 同時填寫每個客戶的必要資料 這絕對不是小活 我從中還要確定出一組客戶作為市場目標。當我從最開始設計表和字段的時候，我試圖不在主索引裡增加太多的字段以便加快資料庫的執行速度。然後我意識到特...
資料庫設計經驗談 4
第 4 部分 保證資料的完整性 如果你按照商務規則來處理需求，那麼你應當檢查商務層次 使用者介面 如果商務規則以後發生變化，那麼只需要進行更新即可。假如需求源於維護資料完整性的需要，那麼在資料庫層面上需要施加限制條件。如果你在資料層確實採用了約束，你要保證有辦法把更新不能通過約束檢查的原因採用使用者...
資料庫設計經驗談1
乙個成功的管理系統，是由 50 的業務 50 的軟體 所組成，而 50 的成功軟體又有 25 的資料庫 25 的程式 所組成，資料庫設計的好壞是乙個關鍵。如果把企業的資料比做生命所必需的血液，那麼資料庫的設計就是應用中最重要的一部分。有關資料庫設計的材料汗牛充棟，大學學位課程裡也有專門的講述。不過，...