1. 自增長primary key

　　采用自增長primary key主要是性能。早期的數(shù)據(jù)庫系統(tǒng)，經(jīng)常采用某種編號，比如身份證號碼，公司編號等等作為數(shù)據(jù)庫表的 primary key。然而，很快，大家就發(fā)現(xiàn)其中的不利之處。

　　比如早期的醫(yī)院管理系統(tǒng)，用身份證號碼作為病人表的 primary key。然而，第一，不是每個人都有身份證；第二，對于國外來的病人，不同國家的病人的證件號碼并不見得沒有重復。因此，用身份證號碼作為病人表的primary key是一個非常糟糕的設計?？紤]到?jīng)]有醫(yī)生或者護士會刻意去記這些號碼，使用自增長primary key是更好的設計。

　　公司編號采用某種特定的編碼方法，這也是早期的數(shù)據(jù)庫系統(tǒng)常見的做法。它的缺點也顯而易見：很容易出現(xiàn)像千年蟲的軟件問題，因為當初設計數(shù)據(jù)庫表的時候設計的位數(shù)太短，導致系統(tǒng)使用幾年后不能滿足要求，只有修改程序才能繼續(xù)使用。問題在于，任何人設計系統(tǒng)的時候，在預計某某編號多少位可以夠用的時候，都存在預計不準的風險。而采用自增長 primary key 則不存在這種問題。同樣的道理，沒有人可以去記這些號碼。

　　使用自增長primary key另外一個原因是性能問題。略有編程常識的人都知道，數(shù)字大小比較比字符串大小比較要快得多。使用自增長primary key可以大大地提高數(shù)據(jù)查找速度。

　　2. 避免用復合主鍵 (compound primary key)

　　這主要還是因為性能問題。數(shù)據(jù)檢索是要用到大量的 primary key 值比較，只比較一個字段比比較多個字段快很多。使用單個 primary key 從編程的角度也很有好處， sql 語句中 where 條件可以寫更少的代碼，這意味著出錯的機會大大減少。

　　3. 雙主鍵

　　雙主鍵是指數(shù)據(jù)庫表有兩個字段，這兩個字段獨立成為主鍵，但又同時存在。 數(shù)據(jù)庫系統(tǒng)的雙主鍵最早用在用戶管理模塊。最早的來源可能是參照操作系統(tǒng)的用戶管理模塊。

　　操作系統(tǒng)的用戶管理有兩個獨立的主鍵：操作系統(tǒng)自己自動生成的隨機ID (Linux, windows的SID)，login id。這兩個ID 都必須是唯一的，不同的是，刪除用戶 test 然后增加一個用戶test，SID 不同，login id 相同。采用雙主鍵主要目的是為了防止刪除后增加同樣的login id 造成的混亂。比如銷售經(jīng)理hellen 本機共享文件給總經(jīng)理peter，一年后總經(jīng)理離開公司，進來一個普通員工peter ，兩個peter 用同樣的 login id，如果只用login id 作操作系統(tǒng)的用戶管理主鍵，則存在漏洞：普通員工peter 可以訪問原來只有總經(jīng)理才能看的文件。操作系統(tǒng)自己自動生成的隨機ID 一般情況下面用戶是看不到的。

　　雙主鍵現(xiàn)在已經(jīng)廣泛用在各種數(shù)據(jù)庫系統(tǒng)中，不限于用戶管理系統(tǒng)。

　　4. 以固定的數(shù)據(jù)庫、表應付變化的客戶需求

　　這主要基于以下幾個因素的考慮：

　?。?）大型 EPR 系統(tǒng)的正常使用、維護需要軟件廠商及其眾多的合作伙伴共同給客戶提供技術服務，包括大量的二次開發(fā)。

　　如果用戶在軟件正常使用過程中需要增加新的表或者數(shù)據(jù)庫，將給軟件廠商及其眾多的合作伙伴帶來難題。

　　（2）軟件升級的需要。

　　沒有一個軟件能夠讓客戶使用幾十上百年不用升級的。軟件升級往往涉及數(shù)據(jù)庫表結構的改變。軟件廠商會做額外的程序將早期版本軟件的數(shù)據(jù)庫數(shù)據(jù)升級到新的版本，但是對于用戶使用過程中生成的表進行處理就比較為難。

　?。?）軟件開發(fā)的需要。

　　使用固定的數(shù)據(jù)庫庫表從開發(fā)、二次開發(fā)來說，更加容易。對于用戶使用過程中生成的表，每次查找數(shù)據(jù)時都要先查表名，再找數(shù)據(jù)，比較麻煩。

　　舉例來說，早期的用友財務軟件用Access 作數(shù)據(jù)庫，每年建立一個新的數(shù)據(jù)庫。很快，用戶和用友公司都發(fā)現(xiàn)，跨年度數(shù)據(jù)分析很難做。因此這是一個不好的設計。在ERP 中，很少有不同的年度數(shù)據(jù)單獨分開。一般來說，所有年份的數(shù)據(jù)都在同一個表中。對于跨國公司甚至整個集團公司都用同一個ERP 系統(tǒng)的時候，所有公司的數(shù)據(jù)都在一起。這樣的好處是數(shù)據(jù)分析比較容易做。

　　現(xiàn)在大多數(shù)數(shù)據(jù)庫系統(tǒng)都能做到在常數(shù)時間內返回一定量的數(shù)據(jù)。比如，Oracle 數(shù)據(jù)庫中，根據(jù)primary key 在 100萬條數(shù)據(jù)中取10 條數(shù)據(jù)，與在1 億條數(shù)據(jù)中取10 條數(shù)據(jù)，時間相差并不多。

　　5. 避免一次取數(shù)據(jù)庫大量數(shù)據(jù)，取大量數(shù)據(jù)一定要用分頁

　　這基本上是現(xiàn)在很多數(shù)據(jù)庫系統(tǒng)設計的基本守則。ERP 系統(tǒng)中超過 100萬條數(shù)據(jù)的表很多，對于很多表中的任何一個，一次取所有的會導致數(shù)據(jù)庫服務器長時間處于停滯狀態(tài)，并且影響其它在線用戶的系統(tǒng)響應速度。

　　一般來說，日常操作，在分頁顯示的情況下面，每次取得數(shù)據(jù)在1-100 之間，系統(tǒng)響應速度足夠快，客戶端基本沒有特別長的停頓。這是比較理想的設計。這也是大型數(shù)據(jù)庫系統(tǒng)往往用ODBC，ADO等等通用的數(shù)據(jù)庫聯(lián)接組件而不用特定的速度較快的專用數(shù)據(jù)庫聯(lián)接組件的原因。因為系統(tǒng)瓶頸在于數(shù)據(jù)庫( Database) 方面(數(shù)據(jù)量大)，而不在于客戶端(客戶端每次只取少量數(shù)據(jù))。

　　在 B/S 數(shù)據(jù)庫系統(tǒng)中，分頁非常普遍。早期的數(shù)據(jù)庫系統(tǒng)經(jīng)常有客戶端程序中一次性取大量數(shù)據(jù)做緩沖?，F(xiàn)在已經(jīng)不是特別需要了，主要原因有：

　　（1）數(shù)據(jù)庫本身的緩沖技術大大提高。

　　大部分數(shù)據(jù)庫都會自動將常用的數(shù)據(jù)自動放在內存中緩沖，以提高性能。

　?。?）數(shù)據(jù)庫聯(lián)接組件的緩沖技術也在提高。

　　包括 ADO 在內的一些數(shù)據(jù)庫聯(lián)接組件都會自動對數(shù)據(jù)結果集(result set)進行緩沖，并且效果不錯。比較新穎的數(shù)據(jù)庫聯(lián)接組件，比如 Hibernate 也加入了一些數(shù)據(jù)結果集緩沖功能。

　　當然，也有一些數(shù)據(jù)庫聯(lián)接組件沒有對數(shù)據(jù)結果集進行緩沖，比如 JDBC Driver，不過幾年之內情況應該有所改觀。也有些不太成功的數(shù)據(jù)緩沖，比如 EJB 中的實體Bean，性能就不盡如人意，實體Bean數(shù)據(jù)也是放在內存中，可能是因為占用內存過多的緣故。

　　相對來說，今天的程序員寫客戶端數(shù)據(jù)緩沖，能夠超過以上兩個緩沖效果的，已經(jīng)比較難了。