【正文】 ，你不妨用特定表的前綴 (比如 CusLastName)來幫助你標識字段。 除非你在使用只面向你的縮寫字段名的系統(tǒng)，否則請盡可能地把字段描述的清楚些。所以，在建立系統(tǒng)存儲客戶信息時，我傾向于在單獨的一個數據表里存儲姓氏字段，而且還附加起始日和終止日等字段，這樣就可以跟蹤這一數據條目的變化。 第 2部分 設計表和字段 檢查各種變化 我在設計數據庫的時候會考慮到哪些數據字段將來可能會發(fā)生變更。一個不變的真理是： 只有我看見了我才知道我想要的是什么 必然會導致大量的返工，因為數據庫沒有達到客戶從來沒有寫下來的需求標準。不要依賴用戶寫下來的需求，真正的需求在客戶的腦袋里。這樣的檢索性能比較低而且容易引起混亂。系統(tǒng)生成的主鍵在報表中很難管理。舉個簡單的例子：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼字段而不要把郵政編碼糅進地址字段里。只是要保證其上的邏輯關系今后能產生效益。模式有助于提高協(xié)作效能，這樣在先期的數據庫設計中幾乎不可能出現大的問題。對 SQL 表達式的文檔化來說這是完全必要的。越早創(chuàng)建越能有助于避免今后面臨的可能混亂，從而可以讓任何了解數據庫的人都明確如何從數據庫中獲得數據。其中至少應該包含每個字段的數據類型和在每個表內的主外鍵。這樣你就可以讓你的客戶糾正你自己的理解然后做好下一步的 ER 設計。采用客戶的術語并且向他們解釋你所想到的和你所聽到的。一旦你明確了業(yè)務需求，你就可以自己做出許多決策了。 了解你的業(yè)務 在你百分百地確定系統(tǒng)從客戶角度滿足其需求之前不要在你的 ER(實體關系 )模式中加入哪怕一個數據表 (怎么，你還沒有模式 ?那請你參看技巧 9)。 在物理實踐之前進行邏輯設計 在深入物理設計之前要先進行邏輯設計。 一定要記住過去的經驗教訓！我們開發(fā)人員還應該通過分享自己的體會和經驗互相幫助。 其他的你還可以參考：薩師煊王珊著數據庫系統(tǒng)概論 暢想未來，但不可忘了過去的教訓 我發(fā)現詢問用戶如何看待未來需求變化非常有用。 獲取數據模式資源手冊 正在尋求示例模式的人可以閱讀《數據模式資源手冊》一書，該書由 Len Silverston、 和 Kent Graziano 編寫，是一本值得擁有的最佳數據建模圖書。我在實現 SQL Server 2021 時用 udf_(或者類似的標記 )標識我編寫的函數。 如果采用了 Microsoft Access，你可以用 qry、 rpt、 tbl 和 mod 等符號來標識對象 (比如 tbl_Employees)。你可能會很快就被這些不同的數據庫要素的名稱搞糊涂了。還有，日期列 [字段 ]最好以 D_作為名字打頭。對列 [字段 ]名應該采用標準的前綴和后綴。表內的列 [字段 ]要針對鍵采用一整套設計規(guī)則。對數據庫表來說，從項目一開始就要確定表名是采用復數還是單數形式。一般來說，考察現有系統(tǒng)對你絕對有好處。顯然，現有系統(tǒng)并不完美，否則你就不必再建立新系統(tǒng)了。 第 1部分 設計數據庫之前 考察現有環(huán)境 在設計一個新數據庫時，你不但應該仔細研究業(yè)務需求而且還要考察現有的系統(tǒng)。 第 4部分 保證數據完整性 討論如何保持數據庫的清晰和健壯，如何把有害數據降低到最小程度。 第 2部分 設計數據庫表 總共 24 個指南性技巧，涵蓋表內字段設計以及應該避免的常見問題等。 所以我歸納歷年來所走的彎路及體會，并在網上找了些對數據庫設計頗有造詣的專業(yè)人士給大家傳授一些設計數據庫的技巧和經驗。 有關數據庫設計的材料汗牛充棟，大學學位課程里也有專門的講述。轉載 推薦 數據庫設計經驗談 轉帖 原文地址： [推薦 ]數據庫設計經驗談 (轉帖 )作者： yinger 090807 來源：一個成功的管理系統(tǒng)，是由： [50%的業(yè)務 +50%的軟件 ]所組成， 而 50%的成功軟件又有 [25%的數據庫 +25%的程序 ]所組成，數據庫設計的好壞是一個關鍵。 如果把企業(yè)的數據比做生命所必需的血液，那么數據庫的設計就是應用中最重要的一部分。 不過，就如我們反復強調的那樣，再好的老師也比不過經驗的教誨。 精選了其中的 60個最佳技巧，并把這些技巧編寫成了本文，為了方便索引其內容劃分為 5個部分： 第 1部分 設計數據庫之前 這一部分羅列了 12個基本技巧，包括命名規(guī)范和明確業(yè)務需求等。 第 3部分 選擇鍵 怎么選擇鍵呢 ?這里有 10個技巧專門涉及系統(tǒng)生成的主鍵的正確用法，還有何時以及如何索引字段以獲得最佳性能等。 第 5部分 各種小技巧 不包括在以上 4個部分中的其他技巧，五花八門，有了它們希望你的數據庫開發(fā)工作會更輕松一些。大多數數據庫項目都不是從頭開始建立的；通常，機構內總會存在用來滿足特定需求的現有系統(tǒng) (可能沒有實現自動計算 )。但是對舊系統(tǒng)的研究可以讓你發(fā)現一些可能會忽略的細微問題。 定義標準的對象命名規(guī)范 一定要定義數據庫對象的命名規(guī)范。此外還要給表的別名定義簡單規(guī)則 (比方說，如果表名是一個單詞，別名就取單詞的前 4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成 4個字母長的別名；如果表的名字由 3個單詞組成，你不妨從頭兩個單詞中各取一個然后從最后一個單詞中再取出兩個字母，結果還是組成 4字母長的別名，其余依次類推 )對工作用表來說，表名可以加上前綴 WORK_后 面附上采用該表的應用程序的名字。比如，如果鍵是數字類型，你可以用 _N作為后綴；如果是字符類型則可以采用 _C 后綴。再如，假如你的表里有好多 money字段，你不妨給每個列 [字段 ]增加一個 _M 后綴。 檢查表名、報表名和查詢名之間的命名規(guī)范。假如你堅持統(tǒng)一地命名這些數據庫的不同組成部分，至少你應該在這些對象名字的開頭用 Table、 Query 或者 Report 等前綴加以區(qū)別。我在和 SQL Server 打交道的時候還用過 tbl來索引表，但我用 sp_pany(現在用 sp_feft_)標識存儲過程，因為在有的時候如果我發(fā)現了更好的處理辦法往往會保存好幾個拷貝。 工欲善其事 ,必先利其器 采用理想的數據庫設計工具，比如： SyBase 公司的 PowerDesign，她支持PB、 VB、 Delphe 等語言，通過 ODBC可以連接市面上流行的 30 多個數據庫，包括 dBase、 FoxPro、 VFP、 SQL Server 等，今后有機會我將著重介紹PowerDesign 的使用。該書包括的章節(jié)涵蓋多種數據領域，比如人 員、機構和工作效能等。這樣做可以達到兩個目的：首先，你可以清楚地了解應用設計在哪個地方應該更具靈活性以及如何避免性能瓶頸；其次，你知道發(fā)生事先沒有確定的需求變更時用戶將和你一樣感到吃驚。即使用戶認為他們再也不需要什么支持了，我們也應該對他們進行這方面的教育，我們都曾經面臨過這樣的時刻 當初要是這么做了該多 好 .。隨著大量的 CASE 工具不斷涌現出來，你的設計也可以達到相當高的邏輯水準，你通常可以從整體上更好地了解數據庫設計所需要的方方面面。了解你的企業(yè)業(yè)務可以在以后的開發(fā)階段節(jié)約大量的時間。 一旦你認為你已經明確了業(yè)務內容，你最好同客戶進行一次系 統(tǒng)的交流。同時還應該用可能、將會和必須等詞匯表達出系統(tǒng)的關系基數。 創(chuàng)建數據字典和 ER圖表 一定要花點時間創(chuàng)建 ER圖表和數據字典。創(chuàng)建 ER圖表和數據字典確實有點費時但對其他開發(fā)人員要了解整個設計卻是完全必要的。 有一份諸如 ER 圖表等最新文檔 其重要性如何強調都不過分，這對表明表之間關系很有用，而數據字典則說明了每個字段的用途以及任何可能存在的別名。 創(chuàng)建模式 一張圖表勝過千言萬語：開發(fā)人員不僅要閱讀和實現它，而且還要用它來幫助自己和用戶對話。模式不必弄的很復雜；甚至可以簡單到手寫在一張紙上就可以了。 從輸入輸出下手 在定義數據庫表和字段需求 (輸入 )時，首先應檢查現有的或者已經設計出的報表、查詢 和視圖 (輸出 )以決定為了支持這些輸出哪些是必要的表和字段。 報表技巧 要了解用戶通常是如何報告數據的：批處理還是在線提交報表 ?時間間隔是每天、每周、每月、每個季度還是每年 ?如果需要的話還可以考慮創(chuàng)建總結表。用戶在具有系統(tǒng)生成主鍵的表內用副鍵進行檢索往往會返回許多重復數據。 理解客戶需求 看起來這應該是顯而易 見的事，但需求就是來自客戶 (這里要從內部和外部客戶的角度考慮 )。你要讓客戶解釋其需求，而且隨著開發(fā)的繼續(xù)，還要經常詢問客戶保證其需求仍然在開發(fā)的目的之中。而更糟的是你對他們需求的解釋只屬于你自己，而且可能是完全錯誤的。比方說，姓氏就是如此 (注意是西方人的姓