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