用友U9,號稱世界級的產品讓我失望
|
admin
2011年1月7日 1:10
本文熱度 30896
|
使用ERP多年,最近有興獲得學習U9的機會.總體來說這款產品從理念上讓人為之一震,感覺真有大產品的架構.本人比較喜歡從技術角度分析問題.拿到產品后發現SOA到底體現在什么地方,如何和第三方產品集成,特別是跨平臺的集成.為搞清楚這一問題,深入到數據庫中分析,另我吃驚、失望。整個U9產品的核心計算幾乎全部通過存儲過程實現，包括MRP計算、ATP計算、成本計算甚至密碼的加密算法也在存儲過程實現。整個系統用了7百多個存儲過程，1百多個類似于存儲過程的標量函數。也許才學疏淺，這種方法怎么實現SOA。同時系統的性能如何保障、安全性如何保障，以下是部分存儲過程或函數的名稱。希望和大家交流，大量使用存儲過程，對一個大型軟件來說是否合適。
FN_ABC_ABCCcompile_GetQty 通過轉換率計算數量
fn_BOM_CalcCumYield 工序累計產出率計算
fn_BOM_GetConvertRatio 獲得不同單位的轉換率
fn_BOM_GetRoundValue 計算數量進行四舍五入
fn_BOM_GetSupplier 獲取供應商
fn_CA_GetMoneyRoundValue 獲取金額絕對值
fn_CRP_CalcBOMCompQty BOM子件用量計算
fn_CRP_CalcResQty 計算資源用量
fn_CRP_CalcWorkDayByOffsetHours 根據偏移量計算工作日結束時間
fn_CRP_CalItemLeadTime 計算提前期
fn_CRP_GetConvertRatio 獲得不同單位轉換率
fn_CRP_GetDayCount 計算兩個日期之間的工作天數
fn_CRP_GetIntervalWorkDays 取兩個日期之間的工作日天數
fn_CRP_GetLeadTime 獲得計算后的提前期
fn_CRP_GetRoundValue 獲取絕對值
fn_CRP_GetUOMRatio
fn_CRP_GetWorkDate 獲得工作日歷日期
fn_CRP_GetWorkDate_Hour 獲得工作日歷小時
fn_CRP_GetWorkDateByOrigCalendar 獲得工作日歷日期
fn_CRP_GetWorkDay 計算工作天數
fn_CRP_GetWorkDays 計算工作天數
aspnet_Membership_GetPassword
aspnet_Membership_GetPasswordWithFormat
aspnet_Membership_GetUserByEmail
aspnet_Membership_GetUserByName
aspnet_Membership_GetUserByUserId
aspnet_Membership_ResetPassword
該文章在 2011/1/7 1:10:28 編輯過
| |
全部評論32 |
|
admin
2011年1月7日 1:11
請教樓主：SOA不是指軟件之間的協同么？同一個軟件也存在這個問題么？
該評論在 2011/1/7 1:11:00 編輯過
|
|
admin
2011年1月7日 1:11
用存儲過程很正確呀.
SOA==>這東西我不了解,但我知道,( 這種名詞,是用來哄人的,樓主別太在意, 真正的: 誰能寫好好程序,誰就是NO1)
存儲過程:可以大大提高運算性能, 并且讓邏輯更加靈活.
(你想一下,不同客戶,只要改改存儲過程即可,無需涉及到"應用程序"這一層)
并且,樓主不知道,存儲過程也可以欠套.是一個非常好的東西.(代碼可以避免重復).
(我是搞開發的)
至于用友U9,我就從沒用過.不敢評論. *_*
該評論在 2011/1/7 1:11:39 編輯過
|
|
admin
2011年1月7日 1:12
純粹的SOA不提倡用存儲過程/函數,把數據庫只視為一個存儲數據的地點,所有的業務邏輯都不在數據庫中實現,在應用服務器中實現業務邏輯.從這個角度講U9肯定不是嚴格的SOA構架.但是,實際使用中,純粹的SOA構架效率存在問題,需要頻繁的讀寫數據,對硬件要求也高(我們的一個ERP,采用類似構架,用了4臺小型機做應用服務器,oracle數據庫unix操作系統).要解決這個問題,需要打破這個模式,折中的辦法是限制存儲過程的使用,別爛用.這又需要仔細的系統設計,用友,顯然不具備這種精雕細作出精品的精神
該評論在 2011/1/7 1:12:16 編輯過
|
|
admin
2011年1月7日 1:12
純粹的SOA不提倡用存儲過程/函數,把數據庫只視為一個存儲數據的地點,所有的業務邏輯都不在數據庫中實現,在應用服務器中實現業務邏輯
-->這種框架有優點,也有缺點: 開發成本高,程序執行效率低.
寫完后,才發現樓上也講到這一點.
該評論在 2011/1/7 1:12:36 編輯過
|
|
admin
2011年1月7日 1:12
存儲過程不是好東西,但程序員都愛用,呵呵
該評論在 2011/1/7 1:12:48 編輯過
|
|
admin
2011年1月7日 1:13
開發成本還好了,沒聽說過有模板這個東西嗎?有積累的軟件開發機構都有模板,固定的套路,設計做好了,規范執行嚴格,軟件工程成熟,真是高中生也可做程序員
該評論在 2011/1/7 1:13:13 編輯過
|
|
admin
2011年1月7日 1:13
QUOTE:
--------------------------------------------------------------------------------
原帖由 alone1998 于 2009-6-26 13:07 發表
存儲過程不是好東西,但程序員都愛用,呵呵
--------------------------------------------------------------------------------
如果你打算支持多種數據庫,那就要用"應用服務器"這個東西,(在這里,可以用標準SQL來寫)
如果只打算支持一個數據庫,那還是建議用存儲過程, 可以成倍地提高的數據運算效率和準確值.
(這里說一下準確值問題: 由于開發工具與數據庫對浮點運算解決方法不同,在大運算中,常會出現二者計算結果不符的現象,
這里你就要以一個為標準)
該評論在 2011/1/7 1:13:47 編輯過
|
|
admin
2011年1月7日 1:14
QUOTE:
--------------------------------------------------------------------------------
原帖由 OKRA-ERP 于 2009-6-26 13:21 發表
暈了，我在我研究學習的那個ERP中，怎么就沒有存儲過程這個概念，甚至連關系和視圖也沒。打開數據庫表，除掉一張張單獨的表單外，什么都沒有。
--------------------------------------------------------------------------------
這說明你這款軟件支持多種數據庫喲.
(不知是福還是禍)
該評論在 2011/1/7 1:14:09 編輯過
|
|
admin
2011年1月7日 1:15
謝謝大家的反饋,我也在學習中.
眾所周知，小型軟件因為邏輯簡單、數據量小，選擇什么數據庫，采取什么技術架構等無關緊要，都能達到目標，盡可能簡單、經濟。
而大型軟件，特別是號稱和SAP叫板的U9采取這樣的技術就有點外行了。
大型軟件至少要包含三層，數據庫層：主要負責存儲，要求有較高的吞吐量；業務邏輯層，也叫中間層：主要負責核心業務處理，如校驗、檢查、計算等，要求安全、可靠；最靠近用戶一層主要用來展現界面，要求表現力豐富，易用、易學。
現在U9把中間層要做的事情都讓數據庫服務器代勞。顯然對數據庫服務器帶來成本的壓力，同時該系統存儲過程都是開放的，任何人都可以隨意修改，對系統的穩定性和安全性帶來隱患。
同時，如果通過存儲過程來實現如MRP計算，如果計算量很大的情況下勢必會造成服務器的資源耗盡，一旦進行MRP計算，所有人都無法工作了。并且，這種計算在前端是無法知道進度的，象死機一樣，當然也無法知道什么時候能夠結束。
大量的計算也回帶來死鎖，乃至癱瘓。
根據我以往的經驗，并發數超過100就很困難了，不可靠了（丟數據、死機等）。要達到200，購買最好的服務器恐怕也困難。
該評論在 2011/1/7 1:15:10 編輯過
|
|
admin
2011年1月7日 1:15
準備支持多數庫的，就不能用存儲過程。
只支持單一數據庫的，可以使用存儲過程來提高算法的效率。
存儲過程和SOA并沒有任何關系。SOA講究的是服務的封裝，標準的SOA中你是無法繞過一個服務去調數據庫底層的。
存儲過程是被服務封裝起來了的。
至于說被人修改什么的，根本不是問題。任何一個數據庫存有權限機制，為何不用？
看來樓主似乎也是一知半解呀。過濾掉漫罵攻擊的貼子，在這個論壇還是可以學到一些東西的。
該評論在 2011/1/7 1:15:42 編輯過
|
|
|
400 186 1886
