1.自增長primarykey

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

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

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

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

　　2.避免用復(fù)合主鍵(compoundprimarykey)

　　這主要還是因?yàn)樾阅軉栴}。數(shù)據(jù)檢索是要用到大量的primarykey值比較，只比較一個(gè)字段比比較多個(gè)字段快很多。使用單個(gè)primarykey從編程的角度也很有好處，sql語句中where條件可以寫更少的代碼，這意味著出錯(cuò)的機(jī)會大大減少。

　　3.雙主鍵

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

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

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

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

　　這主要基于以下幾個(gè)因素的考慮：

　　4.1大型EPR系統(tǒng)的正常使用、維護(hù)需要軟件廠商及其眾多的合作伙伴共同給客戶提供技術(shù)服務(wù)，包括大量的。

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

　　4.2軟件升級的需要。

　　沒有一個(gè)軟件能夠讓客戶使用幾十上百年不用升級的。軟件升級往往涉及數(shù)據(jù)庫表結(jié)構(gòu)的改變。軟件廠商會做額外的程序?qū)⒃缙诎姹拒浖臄?shù)據(jù)庫數(shù)據(jù)升級到新的版本，但是對于用戶使用過程中生成的表進(jìn)行處理就比較為難。

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

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

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

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

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

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

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

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

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

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

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

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

　　當(dāng)然，也有一些數(shù)據(jù)庫聯(lián)接組件沒有對數(shù)據(jù)結(jié)果集進(jìn)行緩沖，比如JDBCDriver，不過幾年之內(nèi)情況應(yīng)該有所改觀。也有些不太成功的數(shù)據(jù)緩沖，比如EJB中的實(shí)體Bean，性能就不盡如人意，實(shí)體Bean數(shù)據(jù)也是放在內(nèi)存中，可能是因?yàn)檎加脙?nèi)存過多的緣故。

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