1. 設計資料庫之前
1. 在物理實踐之前進行邏輯設計
在深入物理設計之前要先進行邏輯設計。隨著大量的 case 工具不斷湧現出來，你的設計也可以達到相當高的邏輯水準，你通常可以從整體上更好地了解資料庫設計所需要的方方面面。
2. 建立資料字典和 er 圖表
一定要花點時間建立 er 圖表和資料字典。其中至少應該包含每個欄位的資料型別和在每個表內的主外來鍵。建立 er 圖表和資料字典確實有點費時但對其他開發人員要了解整個設計卻是完全必要的。有乙份諸如 er 圖表等最新文件其重要性如何強調都不過分，這對表明表之間關係很有用，而資料字典則說明了每個欄位的用途以及任何可能存在的別名。
3. 對於乙個儲存設計，必須充分理解客戶的需求，考慮業務特點，並掌握以下資訊：
1. 資料的容量：1-3年內會大概多少條資料，每條資料大概多少位元組；
2. 資料項：是否有大字段，那些欄位的值是否經常被更新；
3. 預計大表及相關聯的sql，每天總的執行量在何數量級？
4. 表中的資料：更新為主的業務 還是 查詢為主的業務
5. 打算採用什麼資料庫物理伺服器，以及資料庫伺服器架構？
6. 併發如何？
7. 儲存引擎選擇innodb還是myisam？
8. 資料查詢sql條件：哪些資料項的列名稱經常出現在where、group by、order by子句中等；
9. 資料更新類sql條件：有多少列經常出現update或delete 的where子句中；
10. sql量的統計比，如：select：update+delete：insert=多少？
1. 檢查可能的各種變化
我在設計資料庫的時候會考慮到哪些資料字段將來可能會發生變更。比方說，姓氏就是如此（注意是西方人的姓氏，比如女性結婚後從夫姓等）。所以，在建立系統儲存客戶資訊時，我傾向於在單獨的乙個資料表裡儲存姓氏字段，而且還附加起始日和終止日等字段，這樣就可以跟蹤這一資料條目的變化。
資料庫設計時就要考慮效率和優化的問題。一開始就要分析哪些表會儲存較多的資料量，對於資料量較大的表的設計往往是粗粒度的，也會冗餘一些必要的字段，已達到盡量用最少的表、最弱的表關係去儲存海量的資料。並且在設計表時，一般都會對主鍵建立聚集索引，含有大資料量的表更是要建立索引以提供查詢效能。對於含有計算、資料互動、統計這類需求時，還要考慮是否有必要採用儲存過程。
2. 根據具體的業務場景選取最合適的儲存引擎，設計最合理的索引。
3.欄位名的設計
有意義，好記憶；提房大小寫混用；避免特殊字元，保留詞；
假如你給每個表的列[字段]名都採用統一的字首，那麼在編寫 sql 表示式的時候會得到大大的簡化。customer 表的字首是 cu_，所以該錶內的子段名如下：cu_name_id，cu_surname。order 表的字首是 or_ 。
4. 冗餘字段
像「建立時間」、「修改時間」、「備註」、「操作使用者ip」和一些用於其他需求（如統計）的字段等，在每張表中必須都要有，不是說只有系統中用到的資料才會存到資料庫中，一些冗餘欄位是為了便於日後維護、分析、拓展而新增的，這點是非常重要的，比如黑客攻擊，篡改了資料，我們便就可以根據修改時間和操作使用者ip來查詢定位。
商品中的「單價、數量、金額」三個字段，「金額」就是由「單價」乘以「數量」派生出來的，它就是冗餘，而且是一種高階冗餘。冗餘的目的是為了提高處理速度。只有低階冗餘才會增加資料的不一致性。
5.不活躍或者不採用的識別符號
增加乙個字段表示所在記錄是否在業務中不再活躍挺或已經被刪除。
6. 給每張表乙個數字型別自增的id；
7. 仔細選擇資料儲存型別（如smallint，tinyint），盡量使資料緊湊，又不影響擴充套件性。
如果是文字字段長度要留足餘量；如果是bool型字段，使用 bit 作為布林字段，使用整數或者varchar是浪費。同時，這類字段應該以「is」開頭。
8. 盡量避免null
應該指定列為not null，除非你想儲存null。在mysql中，含有空值的列很難進行查詢優化，而且對錶索引時不會儲存null值的，所以如果索引的字段可以為null，索引的效率會下降很多。因為它們使得索引、索引的統計資訊以及比較運算更加複雜。你應該用0、乙個特殊的值或者乙個空串代替空值。
9. 採用檢視為了在你的資料庫和你的應用程式**之間提供另一層抽象，你可以為你的應用程式建立專門的檢視而不必非要應用程式直接訪問資料表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。
10. 存在過期概念的表，在其設計之初就必須有過期機制，且有明確的過期時間。過期資料必須遷移至歷史表中。
1. 文件、文件、文件
對所有的快捷方式、命名規範、限制和函式都要編制文件。採用給表、列[字段]、觸發器等加注釋的資料庫工具。是的，這有點費事，但從長遠來看，這樣做對開發、支援和跟蹤修改非常有用。取決於你使用的資料庫系統，可能有一些軟體會給你一些供你很快上手的文件。
2. 使用常用英語（或者其他任何語言）而不要使用編碼
為什麼我們經常採用編碼（比如 9935a 可能是'青島啤酒'的****，4xf788-q 可能是帳目編碼）？理由很多。但是使用者通常都用英語進行思考而不是編碼。工作 5 年的會計或許知道 4xf788-q 是什麼東西，但新來的可就不一定了。在建立下拉列表、列表、報表時最好按照英語名排序。假如你需要編碼，那你可以在編碼旁附上使用者知道的英語。
3. 儲存常用資訊
讓乙個表專門存放一般資料庫資訊非常有用。我常在這個表裡存放資料庫當前版本、最近檢查/修復（對 foxpro）、關聯設計文件的名稱、客戶等資訊。這樣可以實現一種簡單機制跟蹤資料庫，當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯絡時，這樣做對非客戶機/伺服器環境特別有用。
4. 測試、測試、反覆測試
5. 給資料保有和恢復制定計畫
6. 分布式資料系統 保證資料完整性
對分布式系統而言，在你決定是否在各個站點複製所有資料還是把資料儲存在乙個地方之前應該估計一下未來 5 年或者 10 年的資料量。當你把資料傳送到其他站點的時候，最好在資料庫欄位中設定一些標記。在目的站點收到你的資料之後更新你的標記。為了進行這種資料傳輸，請寫下你自己的批處理或者排程程式以特定時間間隔執行而不要讓使用者在每天的工作後傳輸資料。本地拷貝你的維護資料，比如計算常數和利息率等，設定版本號保證資料在每個站點都完全一致。
資料庫表的設計 注意點
注意點 如果是 表基本不會變化的我們可以只設計 dm欄位而不加pkid欄位 表還會不斷變化的話我們再加乙個pkid自增長，如果涉及到外來鍵我們要引用的是dm而不是pkid，因為這樣我在匯入資料的時候可以避免資料對不上。業務表的話我們還是也加乙個dm 可以guid 欄位好了，pkid自增長或者我們只要...
資料庫注意點
初入sql 1.當你在建立表單時，選擇主鍵後並把主鍵的標識規範 是標識 系統自增 那麼在用insert into 新增內容的時候，勢必要跳過主鍵這一列 student 表 學號 主鍵 姓名班級 錯誤 insert into student values 這樣會報錯，因為學號 已經系統自增了 那麼在插...
資料庫設計 注意項
這篇文章如題所述，只打算談一下資料庫表本身設計，同時講到和表結構相關的效能和擴充套件性問題。下面講到的東西大多是從實際經驗中總結而來，算是對這項技術的乙個反思。基本上在設計資料庫表的時候，首先考慮設計要滿足功能需求，這是最根本的，其次是滿足效能需求，再次則是滿足擴充套件性需求，這一點在大規模系統中是...