1. 設計資料庫之前（需求分析階段）
(1) 理解客戶需求，詢問使用者如何看待未來需求變化。讓客戶解釋其需求，而且隨著開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。
(2) 了解企業業務可以在以後的開發階段節約大量的時間。
(3) 重視輸入輸出。
在定義資料庫表和字段需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和檢視（輸出）以決定為了支援這些輸出哪些是必要的表和字段。
(4) 建立資料字典和er 圖表
er 圖表和資料字典可以讓任何了解資料庫的人都明確如何從資料庫中獲得資料。er圖對表明表之間關係很有用，而資料字典則說明了每個欄位的用途以及任何可能存在的別名。對sql 表示式的文件化來說這是完全必要的。
(5) 定義標準的物件命名規範
資料庫各種物件的命名必須規範。
2. 表和字段的設計（資料庫邏輯設計)
表設計原則
(1) 標準化和規範化（三大正規化）
資料的標準化有助於消除資料庫中的資料冗餘。標準化有好幾種形式，但third normal form（3nf）通常被認為在效能、擴充套件性和資料完整性方面達到了最好平衡。簡單來說，遵守3nf 標準的資料庫的表設計原則是：「one fact in one place」即某個表只包括其本身基本的屬性，當不是它們本身所具有的屬性時需進行分解。表之間的關係通過外來鍵相連線。它具有以下特點：有一組表專門存放通過鍵連線起來的關聯資料。
事實上，為了效率的緣故，對錶不進行標準化有時也是必要的。
(2) 資料驅動
採用資料驅動而非硬編碼的方式，許多策略變更和維護都會方便得多，大大增強系統的靈活性和擴充套件性。
舉例，假如使用者介面要訪問外部資料來源（檔案、xml 文件、其他資料庫等），不妨把相應的連線和路徑資訊儲存在使用者介面支援表裡。還有，如果使用者介面執行工作流之類的任務（傳送郵件、列印信箋、修改記錄狀態等），那麼產生工作流的資料也可以存放在資料庫裡。角色許可權管理也可以通過資料驅動來完成。事實上，如果過程是資料驅動的，你就可以把相當大的責任推給使用者，由使用者來維護自己的工作流過程。
(3) 考慮各種變化
在設計資料庫的時候考慮到哪些資料字段將來可能會發生變更。
舉例，姓氏就是如此（注意是西方人的姓氏，比如女性結婚後從夫姓等）。所以，在建立系統儲存客戶資訊時，在單獨的乙個資料表裡儲存姓氏字段，而且還附加起始日和終止日等字段，這樣就可以跟蹤這一資料條目的變化。
字段設計原則
(4) 每個表中都應該新增的3 個有用的字段
drecordcreationdate，在vb 下預設是now()，而在sql server • 下預設為getdate()
srecordcreator，在sql server 下預設為not null default • user
nrecordversion，記錄的版本標記；有助於準確說明記錄中出現null 資料或者丟失資料的原因 •
(5) 對位址和**採用多個字段
描述街道位址就短短一行記錄是不夠的。address_line1、address_line2 和address_line3 可以提供更大的靈活性。還有，**號碼和郵件位址最好擁有自己的資料表，其間具有自身的型別和標記類別。
(6) 使用角色實體定義屬於某類別的列
在需要對屬於特定類別或者具有特定角色的事物做定義時，可以用角色實體來建立特定的時間關聯關係，從而可以實現自我文件化。
舉例：用person 實體和person_type 實體來描述人員。比方說，當john smith, engineer 提公升為john smith, director 乃至最後爬到john smith, cio 的高位，而所有你要做的不過是改變兩個表person 和person_type 之間關係的鍵值，同時增加乙個日期/時間欄位來知道變化是何時發生的。這樣，你的person_type 表就包含了所有person 的可能型別，比如associate、engineer、director、cio 或者ceo 等。還有個替代辦法就是改變person 記錄來反映新頭銜的變化，不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。
(7) 選擇數字型別和文字型別盡量充足
在sql 中使用smallint 和tinyint 型別要特別小心。比如，假如想看看月銷售總額，總額字段型別是smallint，那麼，如果總額超過了$32,767 就不能進行計算操作了。
而id 型別的文字字段，比如客戶id 或定單號等等都應該設定得比一般想象更大。假設客戶id 為10 位數長。那你應該把資料庫表字段的長度設為12 或者13 個字元長。但這額外佔據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。
(8) 增加刪除標記字段
在表中包含乙個「刪除標記」字段，這樣就可以把行標記為刪除。在關聯式資料庫裡不要單獨刪除某一行；最好採用清除資料程式而且要仔細維護索引整體性。
3. 選擇鍵和索引（資料庫邏輯設計）
鍵選擇原則：
(1) 鍵設計4 原則
為關聯字段建立外來鍵。 •
所有的鍵都必須唯一。 •
避免使用復合鍵。 •
外來鍵總是關聯唯一的鍵字段。 •
(2) 使用系統生成的主鍵
設計資料庫的時候採用系統生成的鍵作為主鍵，那麼實際控制了資料庫的索引完整性。這樣，資料庫和非人工機制就有效地控制了對儲存資料中每一行的訪問。採用系統生成鍵作為主鍵還有乙個優點：當擁有一致的鍵結構時，找到邏輯缺陷很容易。
(3) 不要用使用者的鍵(不讓主鍵具有可更新性)
在確定採用什麼字段作為表的鍵的時候，可一定要小心使用者將要編輯的字段。通常的情況下不要選擇使用者可編輯的字段作為鍵。
(4) 可選鍵有時可做主鍵
把可選鍵進一步用做主鍵，可以擁有建立強大索引的能力。
索引使用原則
索引是從資料庫中獲取資料的最高效方式之一。95%的資料庫效能問題都可以採用索引技術得到解決。
(1) 邏輯主鍵使用唯一的成組索引，對系統鍵（作為儲存過程）採用唯一的非成組索引，對任何外來鍵列採用非成組索引。考慮資料庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。
(2) 大多數資料庫都索引自動建立的主鍵字段，但是可別忘了索引外來鍵，它們也是經常使用的鍵，比如執行查詢顯示主表和所有關聯表的某條記錄就用得上。
(3) 不要索引memo/note 字段，不要索引大型字段（有很多字元），這樣作會讓索引占用太多的儲存空間。
(4) 不要索引常用的小型表
不要為小型資料表設定任何鍵，假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃瞄表空間消耗更多的時間。
4. 資料完整性設計（資料庫邏輯設計）
(1) 完整性實現機制：
實體完整性：主鍵
參照完整性：
父表中刪除資料：級聯刪除；受限刪除；置空值
父表中插入資料：受限插入；遞迴插入
父表中更新資料：級聯更新；受限更新；置空值
dbms對參照完整性可以有兩種方法實現：外來鍵實現機制（約束規則）和觸發器實現機制
使用者定義完整性：
not null；check；觸發器
(2) 用約束而非商務規則強制資料完整性
採用資料庫系統實現資料的完整性。這不但包括通過標準化實現的完整性而且還包括資料的功能性。在寫資料的時候還可以增加觸發器來保證資料的正確性。不要依賴於商務層保證資料完整性；它不能保證表之間（外來鍵）的完整性所以不能強加於其他完整性規則之上。
(3) 強制指示完整性
在有害資料進入資料庫之前將其剔除。啟用資料庫系統的指示完整性特性。這樣可以保持資料的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
(4) 使用查詢控制資料完整性
控制資料完整性的最佳方式就是限制使用者的選擇。只要有可能都應該提供給使用者乙個清晰的價值列表供其選擇。這樣將減少鍵入**的錯誤和誤解同時提供資料的一致性。某些公共資料特別適合查詢：國家**、狀態**等。
(5) 採用檢視
為了在資料庫和應用程式**之間提供另一層抽象，可以為應用程式建立專門的檢視而不必非要應用程式直接訪問資料表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。
5. 其他設計技巧
(1) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在除錯程式時觸發器可能成為干擾。假如你確實需要採用觸發器，你最好集中對它文件化。
(2) 使用常用英語（或者其他任何語言）而不要使用編碼
在建立下拉列表、列表、報表時最好按照英語名排序。假如需要編碼，可以在編碼旁附上使用者知道的英語。
(3) 儲存常用資訊
讓乙個表專門存放一般資料庫資訊非常有用。在這個表裡存放資料庫當前版本、最近檢查/修復（對access）、關聯設計文件的名稱、客戶等資訊。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯絡時，這樣做對非客戶機/伺服器環境特別有用。
(4) 包含版本機制
在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長，使用者的需求總是會改變的。最終可能會要求修改資料庫結構。把版本資訊直接存放到資料庫中更為方便。
(5) 編制文件
對所有的快捷方式、命名規範、限制和函式都要編制文件。
採用給表、列、觸發器等加注釋的資料庫工具。對開發、支援和跟蹤修改非常有用。
對資料庫文件化，或者在資料庫自身的內部或者單獨建立文件。這樣，當過了一年多時間後再回過頭來做第2 個版本，犯錯的機會將大大減少。
(6) 測試、測試、反覆測試
建立或者修訂資料庫之後，必須用使用者新輸入的資料測試資料字段。最重要的是，讓使用者進行測試並且同使用者一道保證選擇的資料型別滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。
(7) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支援的應用程式原型檢查資料庫。換句話說，針對每一種最終表達資料的原型應用，保證你檢查了資料模型並且檢視如何取出資料。
資料庫設計技巧
1.設計資料庫之前 需求分析階段 1 理解客戶需求，詢問使用者如何看待未來需求變化。讓客戶解釋其需求，而且隨著開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。2 了解企業業務可以在以後的開發階段節約大量的時間。3 重視輸入輸出。在定義資料庫表和字段需求 輸入 時，首先應檢查現有的或者已經...
資料庫設計技巧
下述14則資料庫設計技巧，是許多人在大量的資料庫分析與設計實踐中，逐步總結出來的。對於這些資料庫設計經驗的運用，靈活掌握，並逐步做到 在應用中發展，在發展中應用。資料庫設計技巧14則 1.原始單據與實體之間的關係 可以是一對 一 一對多 多對多的關係。在一般情況下，它們是一對一的關係 即一張原始單據...
資料庫設計技巧 下
三 多使用者及其許可權管理的設計 開發資料庫 管理類的軟體，不可能不考慮多使用者和使用者許可權設定的問題。儘管目前市面上的大 中型的後台資料庫系統軟體都提供了多使用者，以及細至某個資料庫內某張表的許可權設定的功能，我個人建議 一套成熟的資料庫管理軟體，還是應該自行設計使用者管理這塊功能，原因有二 1...