【正文】 ：cu_name_id、cu_surname、cu_initials 和cu_address 等。身份證的號碼從 15 位變成 18 位就是最好和最慘痛的例子。比方說，假設你的客戶 ID 為 10 位數(shù)長。時間一長，用戶的需求總是會改變的。在調(diào)試程序時觸發(fā)器可能成為干擾。 仔細選擇數(shù)字類型在 SQL 中使用 smallint 和 tinyint 類型要特別小心，比如，假如你想看看月銷售總額，你的總額字段類型是 smallint，那么，如果總額超過了 $32,767 你就不能進行計算操作了。 保持字段名和類型的一致性在命名字段并為其指定數(shù)據(jù)類型的時候一定要保證一致性。想想看，這種數(shù)據(jù)庫/應用程序能混到采用更強大數(shù)據(jù)庫的那一天嗎？采用全部大寫而且包含下劃符的名字具有更好的可讀性（CUSTOMER_DATA），絕對不要在對象名的字符之間留空格。總之，采用連接字段的方式可以有效的隔離用戶應用和開發(fā)人員界面。我覺得只有剛入門的開發(fā)人員才會這么做，但實際上網(wǎng)上這種做法非常普遍。過分標準化可要小心，這樣做可能會導致性能上出現(xiàn)問題。 數(shù)據(jù)重復需要采用分立的數(shù)據(jù)表如果你發(fā)現(xiàn)自己在重復輸入數(shù)據(jù)，請創(chuàng)建新表和新的關系。同樣的，ORGANIZATION 也可能是 MyCompany、MyDepartment、Competitor、Hospital、Warehouse、Government 等。 采用常用實體命名機構數(shù)據(jù)組織數(shù)據(jù)的最簡單辦法就是采用常用名字，比如：PERSON、ORGANIZATION、ADDRESS 和 PHONE 等等。 使用角色實體定義屬于某類別的列[字段]在需要對屬于特定類別或者具有特定角色的事物做定義時，可以用角色實體來創(chuàng)建特定的時間關聯(lián)關系，從而可以實現(xiàn)自我文檔化。這樣，當你用向?qū)С绦?[Wizards，臺灣人稱為‘精靈’] 創(chuàng)建表單和報表時，其名字會讓那些不是程序員的人更容易閱讀。雖然我不得不這么做，但我絕不把數(shù)據(jù)表的非標準化當作當然的設計理念。更高層次的標準化也有，但更標準是否就一定更好呢？答案是不一定。* 表內(nèi)不應該存儲依賴于其他鍵的非鍵信息。 標準化不能過頭對那些不熟悉標準化一詞（normalization）的人而言，標準化可以保證表內(nèi)的字段都是最基礎的要素，而這一措施有助于消除數(shù)據(jù)庫中的數(shù)據(jù)冗余。比方說，假如你的用戶界面要訪問外部數(shù)據(jù)源（文件、XML 文檔、其他數(shù)據(jù)庫等），你不妨把相應的連接和路徑信息存儲在用戶界面支持表里。 采用前綴命名如果多個表里有好多同一類型的字段（比如 FirstName），你不妨用特定表的前綴（比如 CusLastName）來幫助你標識字段。所以，在建立系統(tǒng)存儲客戶信息時，我傾向于在單獨的一個數(shù)據(jù)表里存儲姓氏字段，而且還附加起始日和終止日等字段，這樣就可以跟蹤這一數(shù)據(jù)條目的變化。一個不變的真理是：“只有我看見了我才知道我想要的是什么”必然會導致大量的返工，因為數(shù)據(jù)庫沒有達到客戶從來沒有寫下來的需求標準。這樣的檢索性能比較低而且容易引起混亂。舉個簡單的例子：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼字段而不要把郵政編碼糅進地址字段里。模式有助于提高協(xié)作效能，這樣在先期的數(shù)據(jù)庫設計中幾乎不可能出現(xiàn)大的問題。越早創(chuàng)建越能有助于避免今后面臨的可能混亂，從而可以讓任何了解數(shù)據(jù)庫的人都明確如何從數(shù)據(jù)庫中獲得數(shù)據(jù)。這樣你就可以讓你的客戶糾正你自己的理解然后做好下一步的 ER 設計。一旦你明確了業(yè)務需求，你就可以自己做出許多決策了。 在物理實踐之前進行邏輯設計在深入物理設計之前要先進行邏輯設計。其他的你還可以參考：[1]薩師煊　王珊著　數(shù)據(jù)庫系統(tǒng)概論(第二版)高等教育出版社 199[2][美] Steven 著 Oracle 7 與客戶／服務器計算技術從入門到精通　劉建元等譯　電子工業(yè)出版社，199[3]周中元　信息系統(tǒng)建模方法(下)　電子與信息化　1999年第3期，1999 暢想未來，但不可忘了過去的教訓我發(fā)現(xiàn)詢問用戶如何看待未來需求變化非常有用。我在實現(xiàn) SQL Server 2000 時用 udf_ （或者類似的標記）標識我編寫的函數(shù)。你可能會很快就被這些不同的數(shù)據(jù)庫要素的名稱搞糊涂了。對列[字段]名應該采用標準的前綴和后綴。對數(shù)據(jù)庫表來說，從項目一開始就要確定表名是采用復數(shù)還是單數(shù)形式。顯然，現(xiàn)有系統(tǒng)并不完美，否則你就不必再建立新系統(tǒng)了。 第 4 部分 保證數(shù)據(jù)完整性討論如何保持數(shù)據(jù)庫的清晰和健壯，如何把有害數(shù)據(jù)降低到最小程度。所以我歸納歷年來所走的彎路及體會，并在網(wǎng)上找了些對數(shù)據(jù)庫設計頗有造詣的專業(yè)人士給大家傳授一些設計數(shù)據(jù)庫的技巧和經(jīng)驗。 CSDN 文檔中心 數(shù)據(jù)庫開發(fā) 閱讀：6246 評論： 4 參與評論 標題 數(shù)據(jù)庫設計經(jīng)驗 選擇自 xlovem 的 Blog 關鍵字 數(shù)據(jù)庫設計經(jīng)驗 出處 一個成功的管理系統(tǒng)，是由：[50% 的業(yè)務 + 50% 的軟件] 所組成，而 50% 的成功軟件又有 [25% 的數(shù)據(jù)庫 + 25% 的程序] 所組成，數(shù)據(jù)庫設計的好壞是一個關鍵。不過，就如我們反復強調(diào)的那樣，再好的老師也比不過經(jīng)驗的教誨。 第 3 部分 選擇鍵怎么選擇鍵呢？這里有 10 個技巧專門涉及系統(tǒng)生成的主鍵的正確用法，還有何 時以及如何索引字段以獲得最佳性能等。大多數(shù)數(shù)據(jù)庫項目都不是從頭開始建立的；通常，機構內(nèi)總會存在用來滿足特定需求的現(xiàn)有系統(tǒng)（可能沒有實現(xiàn)自動計算）。 定義標準的對象命名規(guī)范一定要定義數(shù)據(jù)庫對象的命名規(guī)范。比如，如果鍵是數(shù)字類型，你可以用 _N 作為后綴；如果是字符類型則可以采用 _C 后綴。檢查表名、報表名和查詢名之間的命名規(guī)范。我在和 SQL Server 打交道的時候還用過 tbl 來索引表，但我用 sp_pany （現(xiàn)在用 sp_feft_）標識存儲過程，因為在有的時候如果我發(fā)現(xiàn)了更好的處理辦法往往會保存好幾個拷貝。該書包括的章節(jié)涵蓋多種數(shù)據(jù)領域，比如人員、機構和工作效能等。即使用戶認為他們再也不需要什么支持了，我們也應該對他們進行這方面的教育，我們都曾經(jīng)面臨過這樣的時刻“當初要是這么做了該多好..”。了解你的企業(yè)業(yè)務可以在以后的開發(fā)階段節(jié)約大量的時間。同時還應該用可能、將會和必須等詞匯表達出系統(tǒng)的關系基數(shù)。創(chuàng)建 ER 圖表和數(shù)據(jù)字典確實有點費時但對其他開發(fā)人員要了解整個設計卻是完全必要的。 創(chuàng)建模式一張圖表勝過千言萬語：開發(fā)人員不僅要閱讀和實現(xiàn)它，而且還要用它來幫助自己和用戶對話