『壹』 ERP管理軟體資料庫系統的幾種設計方法
1. 自增長primary key採用自增長primary key主要是性能。早期的資料庫系統，經常採用某種編號，比如身份證號碼，公司編號等等作為資料庫表的primary key。然而，很快，大家就發現其中的不利之處。 比如早期的醫院管理系統，用身份證號碼作為病人表的primary key。然而，第一，不是每個人都有身份證；第二，對於國外來的病人，不同國家的病人的證件號碼並不見得沒有重復。因此，用身份證號碼作為病人表的primary key是一個非常糟糕的設計。考慮到沒有醫生或者護士會刻意去記這些號碼，使用自增長primary key是更好的設計。 公司編號採用某種特定的編碼方法，這也是早期的資料庫系統常見的做法。它的缺點也顯而易見：很容易出現像千年蟲的軟體問題，因為當初設計資料庫表的時候設計的位數太短，導致系統使用幾年後不能滿足要求，只有修改程序才能繼續使用。問題在於，任何人設計系統的時候，在預計某某編號多少位可以夠用的時候，都存在預計不準的風險。而採用自增長primary key 則不存在這種問題。同樣的道理，沒有人可以去記這些號碼。 使用自增長primary key另外一個原因是性能問題。略有編程常識的人都知道，數字大小比較比字元串大小比較要快得多。使用自增長primary key可以大大地提高數據查找速度。 2. 避免用復合主鍵 (compound primary key)這主要還是因為性能問題。數據檢索是要用到大量的 primary key 值比較，只比較一個欄位比比較多個欄位快很多。使用單個primary key 從編程的角度也很有好處， sql 語句中 where 條件可以寫更少的代碼，這意味著出錯的機會大大減少。 3. 雙主鍵雙主鍵是指資料庫表有兩個欄位，這兩個欄位獨立成為主鍵，但又同時存在。 資料庫系統的雙主鍵最早用在用戶管理模塊。最早的來源可能是參照操作系統的用戶管理模塊。 操作系統的用戶管理有兩個獨立的主鍵：操作系統自己自動生成的隨機 ID (Linux, windows 的 SID), login id。這兩個 ID 都必須是唯一的，不同的是，刪除用戶 test 然後增加一個用戶 test, SID 不同，login id 相同。採用雙主鍵主要目的是為了防止刪除後增加同樣的 login id 造成的混亂。比如銷售經理 hellen 本機共享文件給總經理 peter, 一年後總經理離開公司，進來一個普通員工 peter ，兩個peter 用同樣的 login id, 如果只用 login id 作操作系統的用戶管理主鍵，則存在漏洞：普通員工 peter 可以訪問原來只有總經理才能看的文件。操作系統自己自動生成的隨機 ID 一般情況下面用戶是看不到的。 雙主鍵現在已經廣泛用在各種資料庫系統中，不限於用戶管理系統。 4. 以固定的資料庫、表應付變化的客戶需求這主要基於以下幾個因素的考慮： ◆4.1 大型EPR系統的正常使用、維護需要軟體廠商及其眾多的合作夥伴共同給客戶提供技術服務，包括大量的二次開發。 如果用戶在軟體正常使用過程中需要增加新的表或者資料庫，將給軟體廠商及其眾多的合作夥伴帶來難題。 ◆4.2 軟體升級的需要。 沒有一個軟體能夠讓客戶使用幾十上百年不用升級的。軟體升級往往涉及資料庫表結構的改變。軟體廠商會做額外的程序將早期版本軟體的資料庫數據升級到新的版本，但是對於用戶使用過程中生成的表進行處理就比較為難。 ◆4.3 軟體開發的需要。 使用固定的資料庫庫表從開發、二次開發來說，更加容易。對於用戶使用過程中生成的表，每次查找數據時都要先查表名，再找數據，比較麻煩。 舉例來說，早期的用友財務軟體用Access作資料庫，每年建立一個新的資料庫。很快，用戶和用友公司都發現，跨年度數據分析很難做。因此這是一個不好的設計。在 ERP 中，很少有不同的年度數據單獨分開。一般來說，所有年份的數據都在同一個表中。對於跨國公司甚至整個集團公司都用同一個 ERP 系統的時候，所有公司的數據都在一起。這樣的好處是數據分析比較容易做。 現在大多數資料庫系統都能做到在常數時間內返回一定量的數據。比如，Oracle 資料庫中，根據 primary key 在 100萬條數據中取 10 條數據，與在1 億條數據中取 10 條數據，時間相差並不多。 5. 避免一次取資料庫大量數據，取大量數據一定要用分頁這基本上是現在很多資料庫系統設計的基本守則。ERP 系統中超過 100萬條數據的表很多，對於很多表中的任何一個，一次取所有的會導致資料庫伺服器長時間處於停滯狀態，並且影響其它在線用戶的系統響應速度。 一般來說，日常操作，在分頁顯示的情況下面，每次取得數據在 1-100 之間，系統響應速度足夠快，客戶端基本沒有特別長的停頓。這是比較理想的設計。這也是大型資料庫系統往往用 ODBC, ADO 等等通用的資料庫聯接組件而不用特定的速度較快的專用資料庫聯接組件的原因。因為系統瓶頸在於資料庫( Database) 方面(數據量大)，而不在於客戶端(客戶端每次只取少量數據)。 在B/S 資料庫系統中，分頁非常普遍。早期的資料庫系統經常有客戶端程序中一次性取大量數據做緩沖。現在已經不是特別需要了，主要原因有： ◆5.1 資料庫本身的緩沖技術大大提高 大部分資料庫都會自動將常用的數據自動放在內存中緩沖，以提高性能。 ◆5.2 資料庫聯接組件的緩沖技術也在提高。 包括ADO 在內的一些資料庫聯接組件都會自動對數據結果集(result set)進行緩沖，並且效果不錯。比較新穎的資料庫聯接組件，比如 Hibernate 也加入了一些數據結果集緩沖功能。 當然，也有一些資料庫聯接組件沒有對數據結果集進行緩沖，比如 JDBC Driver，不過幾年之內情況應該有所改觀。也有些不太成功的數據緩沖，比如 EJB 中的實體Bean，性能就不盡如人意，實體Bean數據也是放在內存中，可能是因為佔用內存過多的緣故。 相對來說，今天的程序員寫客戶端數據緩沖，能夠超過以上兩個緩沖效果的，已經比較難了。
『貳』 ERP開發需要掌握哪些知識
問的東西太多了。
資料庫存儲，既然為ERP製造服務，應該選sqlserver或者ORACLE。 如果容易避開版權，無所謂用哪個，破解版都行。正版sqlserver單用戶六千左右吧。
自主搭建伺服器，涉及到硬體，價格不不好講了， 配置不樣，價格相差還是挺大的， 不過兩三萬也可以了。數據安全是一個環境問題，物理數據靠災備，網路靠防火牆
編寫軟體，無所謂用哪款開發語言，精通了都可以。
手機APP，你得學移動開發，也是分語言的。
『叄』 資料庫進階：ERP管理軟體資料庫系統的幾種設計方法
自增長primary key
採用自增長primary key主要是性能 早期的資料庫系統 經常採用某種編號 比如身份證號碼 公司編號等等作為資料庫表的primary key 然而 很快 大家就發現其中的不利之處
比如早期的醫院管理系統 用身份證號碼作為病人表的primary key 然而 第一 不是每個人都有身份證;第二 對於國外來的病人 不同國家的病人的證件號碼並不見得沒有重復 因此 用身份證號碼作為病人表的primary key是一個非常糟糕的設計 考慮到沒有醫生或者護士會刻意去記這些號碼 使用自增長primary key是更好的設計
公司編號採用某種特定的編碼方法 這也是早期的資料庫系統常見的做法 它的缺點也顯而易見 很容易出現像千年蟲的軟體問題 因為當初設計資料庫表的時候設計的位數太短 導致系統使用幾年後不能滿足要求 只有修改程序才能繼續使用 問題在於 任何人設計系統的時候 在預計某某編號多少位可以夠用的時候 都存在預計不準的風險 而採用自增長primary key 則不存在這種問題 同樣的道理 沒有人可以去記這些號碼
使用自增長primary key另外一個原因是性能問題 略有編程常識的人都知道 數字大小比較比字元串大小比較要快得多 使用自增長primary key可以大大地提高數據查找速度
避免用復合主鍵 (pound 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數據也是放在內存中 可能是因為佔用內存過多的緣故
lishixin/Article/program/SQL/201311/16157