自增長primary key
采用自增長primary key主要是性能早期的數據庫系統經常采用某種編號比如身份證號碼公司編號等等作為數據庫表的primary key然而很快大家就發現其中的不利之處
比如早期的醫院管理系統用身份證號碼作為病人表的primary key然而第一不是每個人都有身份證;第二對於國外來的病人不同國家的病人的證件號碼並不見得沒有重復因此用身份證號碼作為病人表的primary key是一個非常糟糕的設計考慮到沒有醫生或者護士會刻意去記這些號碼使用自增長primary key是更好的設計
公司編號采用某種特定的編碼方法這也是早期的數據庫系統常見的做法它的缺點也顯而易見很容易出現像千年蟲的軟件問題因為當初設計數據庫表的時候設計的位數太短導致系統使用幾年後不能滿足要求只有修改程序才能繼續使用問題在於任何人設計系統的時候在預計某某編號多少位可以夠用的時候都存在預計不准的風險而采用自增長primary key 則不存在這種問題同樣的道理沒有人可以去記這些號碼
使用自增長primary key另外一個原因是性能問題略有編程常識的人都知道數字大小比較比字符串大小比較要快得多使用自增長primary key可以大大地提高數據查找速度
避免用復合主鍵 (compound primary key)
這主要還是因為性能問題數據檢索是要用到大量的 primary key 值比較只比較一個字段比比較多個字段快很多使用單個primary key 從編程的角度也很有好處 sql 語句中 where 條件可以寫更少的代碼這意味著出錯的機會大大減少
雙主鍵
雙主鍵是指數據庫表有兩個字段這兩個字段獨立成為主鍵但又同時存在 數據庫系統的雙主鍵最早用在用戶管理模塊最早的來源可能是參照操作系統的用戶管理模塊
操作系統的用戶管理有兩個獨立的主鍵操作系統自己自動生成的隨機 ID (Linux windows 的 SID) login id這兩個 ID 都必須是唯一的不同的是刪除用戶 test 然後增加一個用戶 test SID 不同login id 相同采用雙主鍵主要目的是為了防止刪除後增加同樣的 login id 造成的混亂比如銷售經理 hellen 本機共享文件給總經理 peter 一年後總經理離開公司進來一個普通員工 peter 兩個peter 用同樣的 login id 如果只用 login id 作操作系統的用戶管理主鍵則存在漏洞普通員工 peter 可以訪問原來只有總經理才能看的文件操作系統自己自動生成的隨機 ID 一般情況下面用戶是看不到的
雙主鍵現在已經廣泛用在各種數據庫系統中不限於用戶管理系統
以固定的數據庫表應付變化的客戶需求
這主要基於以下幾個因素的考慮
大型EPR系統的正常使用維護需要軟件廠商及其眾多的合作伙伴共同給客戶提供技術服務包括大量的二次開發
如果用戶在軟件正常使用過程中需要增加新的表或者數據庫將給軟件廠商及其眾多的合作伙伴帶來難題
軟件升級的需要
沒有一個軟件能夠讓客戶使用幾十上百年不用升級的軟件升級往往涉及數據庫表結構的改變軟件廠商會做額外的程序將早期版本軟件的數據庫數據升級到新的版本但是對於用戶使用過程中生成的表進行處理就比較為難
軟件開發的需要
使用固定的數據庫庫表從開發二次開發來說更加容易對於用戶使用過程中生成的表每次查找數據時都要先查表名再找數據比較麻煩
舉例來說早期的用友財務軟件用Access作數據庫每年建立一個新的數據庫很快用戶和用友公司都發現跨年度數據分析很難做因此這是一個不好的設計在 ERP 中很少有不同的年度數據單獨分開一般來說所有年份的數據都在同一個表中對於跨國公司甚至整個集團公司都用同一個 ERP 系統的時候所有公司的數據都在一起這樣的好處是數據分析比較容易做
現在大多數數據庫系統都能做到在常數時間內返回一定量的數據比如Oracle 數據庫中根據 primary key 在 萬條數據中取 條數據與在 億條數據中取 條數據時間相差並不多
避免一次取數據庫大量數據取大量數據一定要用分頁
這基本上是現在很多數據庫系統設計的基本守則ERP 系統中超過 萬條數據的表很多對於很多表中的任何一個一次取所有的會導致數據庫服務器長時間處於停滯狀態並且影響其它在線用戶的系統響應速度
一般來說日常操作在分頁顯示的情況下面每次取得數據在 之間系統響應速度足夠快客戶端基本沒有特別長的停頓這是比較理想的設計這也是大型數據庫系統往往用 ODBC ADO 等等通用的數據庫聯接組件而不用特定的速度較快的專用數據庫聯接組件的原因因為系統瓶頸在於數據庫( Database) 方面(數據量大)而不在於客戶端(客戶端每次只取少量數據)
在 B/S 數據庫系統中分頁非常普遍早期的數據庫系統經常有客戶端程序中一次性取大量數據做緩沖現在已經不是特別需要了主要原因有
數據庫本身的緩沖技術大大提高
大部分數據庫都會自動將常用的數據自動放在內存中緩沖以提高性能
數據庫聯接組件的緩沖技術也在提高
包括 ADO 在內的一些數據庫聯接組件都會自動對數據結果集(result set)進行緩沖並且效果不錯比較新穎的數據庫聯接組件比如 Hibernate 也加入了一些數據結果集緩沖功能
當然也有一些數據庫聯接組件沒有對數據結果集進行緩沖比如 JDBC Driver不過幾年之內情況應該有所改觀也有些不太成功的數據緩沖比如 EJB 中的實體Bean性能就不盡如人意實體Bean數據也是放在內存中可能是因為占用內存過多的緣故
相對來說今天的程序員寫客戶端數據緩沖能夠超過以上兩個緩沖效果的已經比較難了
From:http://tw.wingwit.com/Article/program/SQL/201311/16157.html
