1. 考察現有環境
在設計乙個新資料庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫
專案都不是從頭開始建立的；通常，機構內總會存在用來滿足特定需求的現有系統（可能沒有實
現自動計算）。顯然，現有系統並不完美，否則你就不必再建立新系統了。但是對舊系統的研究
可以讓你發現一些可能會忽略的細微問題。一般來說，考察現有系統對你絕對有好處。
— lamont adams
我曾經接手過乙個為地區運輸公司開發的資料庫專案，活不難，用的是access 資料庫。我設定
了一些專案設計引數，而且同客戶一道對這些引數進行了評估，事先還檢視了開發環境下所採取
的工作模式，等到最後部署應用的時候，只見終端上出了幾個提示符然後立馬在我面前翹辮子
了！抓耳撓腮的折騰了好幾個小時，我才意識到，原來這家公司的網路上跑著兩個資料庫應用，
而對網路的訪問需要明確和嚴格的使用者帳號及其訪問許可權。明白了這一點，問題迎刃而解：只需
採用客戶的系統即可。這個專案給我的教訓就是：記住，假如你在諸如access 或者interbase 這
類公共環境下開發應用程式，一定要從表面下手深入系統內部搞清楚你面臨的環境到底是怎麼回
事。— kg
2. 定義標準的物件命名規範
一定要定義資料庫物件的命名規範 。對資料庫表來說，從專案一開始就要確定表名是採用複數還
是單數形式。此外還要給表的別名定義簡單規則（比方說，如果表名是乙個單詞，別名就取單詞
的前4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成4 個字母長的別名；如
果表的名字由3 個單詞組成，你不妨從頭兩個單詞中各取乙個然後從最後乙個單詞中再取出兩個
字母，結果還是組成4 字母長的別名，其餘依次類推）對工作用表來說，表名可以加上字首
work_ 後面附上採用該錶的應用程式的名字。[color=blue]表內的列要針對鍵採用一整套設計規則。比如，
如果鍵是數字型別，你可以用_no 作為字尾；如果是字元型別則可以採用 _code 字尾。對列名
應該採用標準的字首和字尾。再如，假如你的表裡有好多「money」字段，你不妨給每個列增加
乙個_amt 字尾。還有，日期列最好以date_作為名字打頭。[/color]— richard
檢查表名、報表名和查詢名之間的命名規範。你可能會很快就被這些不同的資料庫要素的名稱搞
糊塗了。假如你堅持統一地命名這些資料庫的不同組成部分，至少你應該在這些物件名字的開頭
用table、query 或者report 等字首加以區別。
— rrydenm
如果採用了microsoft access，你可以用 qry、rpt、 tbl 和mod 等符號來標識物件（比如
tbl_employees）。我在和sql server（或者oracle）打交道的時候還用過tbl 來索引表，但我
用sp_company （現在用sp_feft_）標識儲存過程，因為在有的時候如果我發現了更好的處理辦
法往往會儲存好幾個拷貝。我在實現 sql server 2000 時用udf_ （或者類似的標記）標識我編
寫的函式。
— timothy j. bruce
3. 預先計畫
上個世紀80 年代初，我還在使用資產帳目系統和system 38 平台，那時我負責設計所有的日期
字段，這樣在不費什麼力氣的情況下將來就可以輕鬆處理2000 年問題了。許多人給我說就別去
解決這一問題了，因為要處理起來太麻煩了（這在世人皆知的y2k 問題之前很久了）。我回擊說
只要預先計畫今後就不會遇到**煩。結果我只用了兩周的時間就把程式全部改完了。因為預先
計畫的好，後來y2k 問題對該系統的危害降到了最低程度（最近聽說該程式甚至到了1995 年都
還執行在as/400 系統上，唯一出現的小問題是從**中刪除注釋費了點工夫）。
— generalist
4. 獲取資料模式資源手冊
正在尋求示例模式的人可以閱讀《 資料模式資源手冊 》一書，該書由len silverston、w. h.
inmon 和kent graziano 編寫，是一本值得擁有的最佳資料建模圖書。該書包括的章節涵蓋多種
資料領域，比如人員、機構和工作效能等。
— minstrelmike
5. 暢想未來，但不可忘了過去的教訓
我發現詢問使用者如何看待未來需求變化非常有用。這樣做可以達到兩個目的：首先，你可以清楚
地了解應用設計在哪個地方應該更具靈活性以及如何避免效能瓶頸；其次，你知道發生事先沒有
確定的需求變更時使用者將和你一樣感到吃驚。
— chrisdk
[color=blue]一定要記住過去的經驗教訓！我們開發人員還應該通過分享自己的體會和經驗互相幫助。即使用
戶認為他們再也不需要什麼支援了，我們也應該對他們進行這方面的教育，我們都曾經面臨過這
樣的時刻「當初要是這麼做了該多好⋯⋯」。[/color]— dhattrem
6. 在物理實踐之前進行邏輯設計
[color=blue]在深入物理設計之前要先進行邏輯設計。隨著大量的 case 工具不斷湧現出來，你的設計也可以
達到相當高的邏輯水準，你通常可以從整體上更好地了解資料庫設計所需要的方方面面。[/color]— chardove
7. 了解你的業務
在你百分百地確定系統從客戶角度滿足其需求之前不要在你的er（實體關係）模式中加入哪怕
乙個資料表（怎麼，你還沒有模式？那請你參看技巧9）。了解你的企業業務可以在以後的開發
階段節約大量的時間。一旦你明確了業務需求，你就可以自己做出許多決策 了。
— rangel
一旦你認為你已經明確 了業務內容，你最好同客戶進行一次系統的交流。採用客戶的術語並且向
他們解釋你所想到的和你所聽到的。同時還應該用可能、將會和必須等詞彙表達出系統的關係基
數。這樣你就可以讓你的客戶糾正你自己的理解然後做好下一步的er 設計。
— teburlew
8. 建立資料字典和er 圖表
[color=blue]一定要花點時間建立er 圖表和資料字典。其中至少應該包含每個欄位的資料型別和在每個表內
的主外來鍵。建立er 圖表和資料字典確實有點費時但對其他開發人員要了解整個設計卻是完全必
要的。越早建立越能有助於避免今後面臨的可能混亂，從而可以讓任何了解資料庫的人都明確如
何從資料庫中獲得資料。[/color]— bgumbert
[color=blue]
有乙份諸如er 圖表等最新文件其重要性如何強調都不過分，這對表明表之間關係很有用，而數
據字典則說明了每個欄位的用途以及任何可能存在的別名。對sql 表示式的文件化來說這是完
全必要的。[/color]— vanduin.chris.cj
9. 建立模式
模式有助於提高協作效能，這樣在先期的資料庫設計中幾乎不可能出現大的問題。模式不必弄的
很複雜；甚至可以簡單到手寫在一張紙上就可以了。只是要保證其上的邏輯關係今後能產生效
益。[/color]— dana daigle
10. 從輸入輸出下手
[color=blue]在定義資料庫表和字段需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和檢視
（輸出）以決定為了支援這些輸出哪些是必要的表和字段。舉個簡單的例子：假如客戶需要乙個
碼糅進製址字段裡。[/color]
— peter.marshall
11. 報表技巧
每個季度還是每年？如果需要的話還可以考慮建立總結表。系統生成的主鍵在報表中很難管理。
使用者在具有系統生成主鍵的表內用副鍵進行檢索往往會返回許多重複資料。這樣的檢索效能比較
低而且容易引起混亂。
— kol
12. 理解客戶需求
看起來這應該是顯而易見的事，但需求就是來自客戶（這裡要從內部和外部客戶的角度考慮）。
不要依賴使用者寫下來的需求，真正的需求在客戶的腦袋裡。你要讓客戶解釋其需求，而且隨著開
發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。乙個不變的真理是：「只有我
看見了我才知道我想要的是什麼」必然會導致大量的返工，因為資料庫沒有達到客戶從來沒有寫
下來的需求標準。而更糟的是你對他們需求的解釋只屬於你自己，而且可能是完全錯誤的。
— kgilson
資料庫設計 設計資料庫之前
1.考察現有環境 在設計乙個新資料庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫 專案都不是從頭開始建立的 通常，機構內總會存在用來滿足特定需求的現有系統 可能沒有實 現自動計算 顯然，現有系統並不完美，否則你就不必再建立新系統了。但是對舊系統的研究 可以讓你發現一些可能會忽略...
資料庫設計 設計資料庫之前
1.考察現有環境 在設計乙個新資料庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫 專案都不是從頭開始建立的 通常，機構內總會存在用來滿足特定需求的現有系統 可能沒有實 現自動計算 顯然，現有系統並不完美，否則你就不必再建立新系統了。但是對舊系統的研究 可以讓你發現一些可能會忽略...
資料庫設計 設計資料庫之前
1.考察現有環境 在設計乙個新資料庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫 專案都不是從頭開始建立的 通常，機構內總會存在用來滿足特定需求的現有系統 可能沒有實 現自動計算 顯然，現有系統並不完美，否則你就不必再建立新系統了。但是對舊系統的研究 可以讓你發現一些可能會忽略...