滾成本的時候100%整個快死掉一樣而且還要滾5H真是天荒地老，
品號也只不過40多萬筆而已..
我們以前將 滾成本 從 8 小時 改成 80秒
這與 Stored Procedure 有關
與機器無關
機器好壞不會差 10倍
程式好壞會差 100倍
回答：assaxc( iT邦初學者10級 )
時間：2011-01-21 14:55:47
0人
建議ERP伺服器真的要花多一點錢買，像我公司用X3650當初也是想省一些錢也是用WFGP結果才用三年現在CPU工做平常30-40%再跑，滾成本的時候100%整個快死掉一樣而且還要滾5H真是天荒地老，品號也只不過40多萬筆而已..現在想要換掉但是DSX他們說安裝費要4萬，怎麼辦?為了接省人工時間還是得換伺服器加到雙CPU，RAM加到12G以上估計20萬，再來就是主機轉移費還有EIS轉移費TOTAL預計要30萬才能搞定....建議真的一開始就買好一點免得後面衍生出更多問題。
已邀請的邦友 {{ invite_list.length }}/5
程式好壞會差 100倍
simon581923提到：
台灣軟業不重視程式設計師的代價, 寫出來的程式品質真的很糟榚..
raytracy提到：
不願意遵守制度, 只想要無限度的自由, 缺乏團隊觀念, 更缺乏規劃能力.
raytracy提到：
因為台灣的程式設計師太難管, 人人都不願意遵守制度, 只想要無限度的自由, 缺乏團隊觀念, 更缺乏規劃能力.
tecksin提到：
程式設計師 可以代換成 大部分的工程師
albertachen提到：
你怎麼一天到晚無法收尾
你是規劃又施工
施工又規劃
又是代工
又是品牌
乾脆
不要玩軟體好不好
albertachen提到：
要步要來試試看
不是硬體問題
要步要來試試看
你RAM加到12G以上
我來教你好寫你的滾成本
我用原來的 RAM
我比妳快一倍的話你付我 要付給 RAM 20萬 的 1/2
raytracy提到：
前面曾有網友問我, 調個設定怎麼能收好幾萬? 別人去卻只能白做工?...
albertachen提到：
建議真的一開始就買好一點免得後面衍生出更多問題。
raytracy提到：
我跟客戶對賭, 客戶輸了就付錢, 我輸了就摸摸鼻子走人....
antijava提到：
升級硬體，調校軟體
antijava提到：
正解是
升級硬體，調校軟體
simon581923提到：
那....Ray超人老大最後是.....?
(搬桌、擺椅、泡茶...請...Ray老大請講...)
raytracy提到：
某連鎖體系的總管理處, 我們花將近兩年時間, 幫她做完 BPR, 導入 ERP 之後, 將每月庫存量從原本 30% 降低到 5% 以下, 每年省下數千萬週轉金. 賭金是: 上線後第一年省下的錢歸我們團隊
)
raytracy提到：
目前還負債千萬, 正努力爬起中....
player提到：
資料表要正規化啦
antijava提到：所以, 不能拿 IT 當成主題來切入.
BPR - 商業流程要先改變
配合流程的改變，組織(人事)要跟著變動
組織(人事)功能的改變，最後才是IT系統的配合
如此龐大規模的改變
你如何證明ROI, Income增加, 成本降低
都全然是你IT系統導入的功勞
raytracy提到：
台灣似乎很少有部門會配置 DBA 的職位...
raytracy提到：
台灣似乎很少有部門會配置 DBA 的職位...
raytracy提到：
其實, 遊說是一件非常漫長的過程, 佈線經常要長達半年到一年以上的時間. 而且不能只跟總經理一個人說, 必須上至董事會, 下至一級主管,
raytracy提到：
有時, 過度的正規化反而會降低速度; 此時反而需要適時的「反正規化」(Denormalize)....
bizpro提到：
正是正規化不全的問題導至系統必需不斷的以JOIN來頭痛醫頭, 腳痛醫腳.
albertachen提到：
不需到處 join
tecksin提到：
客戶知道自己要什麼卻說不出來
業務聽不懂客戶真正的需求
工程師(程式設計師)寫不出來客戶要的東西
bizpro提到：
要"佈線"很久, 佈線是為了找到"key persons"
bizpro提到：我非常贊同 bizpro 兄的這個論點, 軟體人員如果不能了解真正的商業邏輯, 或是邏輯背後的意義, 在整個開發過程中, 就只能被客戶的聯絡窗口牽著鼻子走, 很可能多走很多冤枉路...
使得這個欄位的存在有其獨立性, 這個商業邏輯存在真實的環境中很久了, 只是很多人忽略了. 這也是我為什麼會認為要從商業邏輯上找出真相, 而非資料庫.
bizpro提到：
因為我找到了一個存在很久的商業邏輯, 使得這個欄位的存在有其獨立性, 這個商業邏輯存在真實的環境中很久了, 只是很多人忽略了. 這也是我為什麼會認為要從商業邏輯上找出真相, 而非資料庫.
raytracy提到：
Do the right thing 要比 Do the things right 更優先....
演算法跟資料結構問題
pan tc 328 大阿哥 英明
正黃旗 恭親王 亞伯王 敬上
資料不一定要在SP裡算.
資料庫裡跑的邏輯跟AP跑的邏輯不一樣.
有時將資料撈到前端算完後再寫回資料庫可能會比較快.
直接加減可能比較慢 ..
直接讀取 後搬出去 再加減 再搬回來 再寫入 可能必較快 ..
難怪 SAP 10分鐘 比較慢
JDE 400 分鐘 比較快
10分鐘 比較慢倒閉
400 分鐘 比較快倒閉
用 Stored Procedure 提升運算 系統真的比較慢 被換掉
有些好幾十層你用這種方式絕對掛.
你不如將關連變成XML的樹狀結構去算比較快.
這是土產軟體 好好笑的設計
明明是工單的製程有10個
就變成 10階
真是好好笑的設計
一般 BOM 表超過 5/6階的
幾乎都是製程編成 BOM 不是真的有 10 階的 BOM
iThome鐵人賽
看影片追技術