iT邦幫忙

0

ERP 滾成本的時候100%整個快死掉

滾成本的時候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萬才能搞定....建議真的一開始就買好一點免得後面衍生出更多問題。

看更多先前的討論...收起先前的討論...
總裁 iT邦好手 1 級 ‧ 2011-01-21 15:44:10 檢舉
程式好壞會差 100倍

終於看懂了一句....筆記
總裁 iT邦好手 1 級 ‧ 2011-01-21 15:45:30 檢舉
還有之前RAY大超人說的系統參數也影響很大.
ycl8000 iT邦高手 1 級 ‧ 2011-01-21 15:46:32 檢舉
資料庫結構好壞也會差很大.
賽門 iT邦超人 1 級 ‧ 2011-01-21 16:12:46 檢舉
總算在呆伯特樂園裏有可以接上話的地方了....

程式設計的好壞, 真的對執行效能影響很大.

我公司現行的ERP系統, 有時候跑起來真的超慢, 慢到User打電話出氣..不..打電話到資訊室來出氣.

用SQL Profiler一看...

一大堆: SELECT * FROM TableA A, TableB B where A.xxx = B.xxx或是SELECT * FROM TableA WHERE 1=0 或是SELECT * FROM TableA WHERE 1=1 的語法.

也沒提供Purge交易檔的功能和歷史交易記錄檔存檔查詢功能, 所有資料都塞在正式的交易
Table中, 結果查個昨天的到貨資料, 就'累格'在那邊.

這就是台灣軟業不重視程式設計師的代價, 寫出來的程式品質真的很糟榚...
總裁 iT邦好手 1 級 ‧ 2011-01-21 16:17:32 檢舉
simon581923提到:
台灣軟業不重視程式設計師的代價, 寫出來的程式品質真的很糟榚..

這應該是不重視QA的結果, 如果QA有嚴格把關, 就不會有這種現象了.
simon大舉的這個例子讓我聯想起IO-bound和CPU-bound的論證

在相同環境條件下
1.SELECT * FROM MYTABLE(什麼條件都不下)

2.SELECT * FROM AA A, BB B, CC C WHERE A.F1=B.F1 INNER JOIN B.F2=C.F2 OUTER JOIN A.F3=C.F3...
(就是where後面一堆條件式 join 來 join 去)

以上兩者何者效率較差?
raytracy iT邦大神 1 級 ‧ 2011-01-21 16:53:24 檢舉
+1 ....台灣只會寫程式(Coding), 不會管軟體 QA....

半導體製程已經世界第一了, 軟體製程卻還停留在 30 年前的打卡時代...
個人工作室/小型軟體商, 程式能如期交貨就已經謝天謝地, 沒人敢再管品質...

ERP 業務很會塞設備給客戶, 卻不敢承諾: 這些設備可以承載多大的業務量....

有慘痛教訓的客戶, 知道軟體商不可靠, 轉向系統商求助, 卻面臨軟體商傲慢的不合作....

沒有導入經驗的客戶, 只能像待宰羔羊, 看著軟體上線, 看著軟體卡死, 看著花下去的幾百萬元, 沒有辦法換成更高效的產能, 卻一籌莫展, 從此對 IT 產生極大的不信任感, 覺得 IT 只是來騙錢的....

不過, 說真的, 就算叫我出來經營軟體業, 也不一定能改善以上現象; 因為台灣的程式設計師太難管, 人人都不願意遵守制度, 只想要無限度的自由, 缺乏團隊觀念, 更缺乏規劃能力.

我自己寫程式, 可能要先想個 30 天, 最後花一天寫出來...
現在的程設師, 可能第一天就寫出來, 然後接著玩 30 天....
(同樣只花一天寫出程式, 但兩者的品質卻天差地遠)

除非只有我自己一個人寫, 否則我也管不動上面這種程式師....
總裁 iT邦好手 1 級 ‧ 2011-01-21 17:00:49 檢舉
海綿大, 您舉的例子我看不懂耶, 既然兩個command都知道了, 跑看看就知道輸贏了呀, 有啥好論證的??...疑惑
賽門 iT邦超人 1 級 ‧ 2011-01-21 17:03:51 檢舉
raytracy提到:
不願意遵守制度, 只想要無限度的自由, 缺乏團隊觀念, 更缺乏規劃能力.

同感 + 1.

曾經和某外國軟體設計團隊合作, 他們是花好大的功夫開系統規格書, 厚厚的一大本規格書...

然後, 交給程式設計師寫系統, 因為開規格書時, 就把Prototype做好了, 程式設計師只是按規格完成細部設計.

而且, 規格書之外, 還一大堆程式設計規範, 要求程式設計人員Follow up.

相較之下, 台灣的程式設計師真的太自由、太好過日子了.
總裁 iT邦好手 1 級 ‧ 2011-01-21 17:28:40 檢舉
應該是整個軟體工程都不重視, 從一開始的SA就搞不清楚客戶需求, SD又沒有整體的概念, 只D自己的部分, PROGRAMMER又不好好看文件, 連最後把關的QA也只是橡皮圖章, 整個環節都很鬆散, 當然蓋不出好房子.
這個議題再討論下去就要延伸到再造工程了.
老圖推出...
鐵殼心 iT邦高手 1 級 ‧ 2011-01-21 17:49:59 檢舉
raytracy提到:
因為台灣的程式設計師太難管, 人人都不願意遵守制度, 只想要無限度的自由, 缺乏團隊觀念, 更缺乏規劃能力.

程式設計師 可以代換成 大部分的工程師落寞
Albert iT邦高手 1 級 ‧ 2011-01-21 17:52:34 檢舉
RAM加到12G以上估計20萬,
再來就是主機轉移費還有EIS轉移費TOTAL預計要30萬才能搞定....
建議真的一開始就買好一點免得後面衍生出更多問題。

你錯了
不是硬體問題
要步要來試試看
你RAM加到12G以上
我來教你好寫你的滾成本
我用原來的 RAM
我比妳快一倍的話你付我 要付給 RAM 20萬 的 1/2
保證把你教會
讓你一路狂飆

Skype: Adempiere/Compiere 技術轉移顧問
tecksin提到:
程式設計師 可以代換成 大部分的工程師


我知道albertachen大大會說什麼偷笑
albertachen提到:

你怎麼一天到晚無法收尾

你是規劃又施工
施工又規劃
又是代工
又是品牌
乾脆
不要玩軟體好不好
Albert iT邦高手 1 級 ‧ 2011-01-21 17:55:12 檢舉
修辭時間::
albertachen提到:
要步要來試試看

要不要來試試看
raytracy iT邦大神 1 級 ‧ 2011-01-21 18:06:12 檢舉
不是硬體問題
要步要來試試看
你RAM加到12G以上
我來教你好寫你的滾成本
我用原來的 RAM
我比妳快一倍的話你付我 要付給 RAM 20萬 的 1/2


+1......

前面曾有網友問我, 調個設定怎麼能收好幾萬? 別人去卻只能白做工?...

正如 Albert 大所述: 我跟客戶對賭, 客戶輸了就付錢, 我輸了就摸摸鼻子走人....
鐵殼心 iT邦高手 1 級 ‧ 2011-01-21 18:12:59 檢舉
raytracy提到:
前面曾有網友問我, 調個設定怎麼能收好幾萬? 別人去卻只能白做工?...

所以要跟我們的業務講, 效能調校不可以是贈品...
鐵殼心 iT邦高手 1 級 ‧ 2011-01-21 18:15:09 檢舉
albertachen提到:
建議真的一開始就買好一點免得後面衍生出更多問題。

效能不好, 很多客戶都會先入為主的認為是硬體等級不夠...無言
賽門 iT邦超人 1 級 ‧ 2011-01-21 18:17:07 檢舉
raytracy提到:
我跟客戶對賭, 客戶輸了就付錢, 我輸了就摸摸鼻子走人....

那....Ray超人老大最後是.....?

(搬桌、擺椅、泡茶...請...Ray老大請講...)
player iT邦大師 1 級 ‧ 2011-01-21 18:30:26 檢舉
資料表要正規化啦
還有如果跨Table Select很多的話
建議使用資料倉儲與資料清理的技巧
這樣才能夠改進Select時的效能
如果DB的Size超過RAM的1/2以上的話, 請考慮加RAM
因為有些排序演算法必須使用到2倍的RAM
Albert iT邦高手 1 級 ‧ 2011-01-21 18:34:22 檢舉
3 到 6 階 BOM 表
滾成本 不是每一個料號 從第一階滾到最底階 !!!
滾成本是從
BOM 表的用料已經算成成本 歸空
LOOP ...
BOM 表的用料 不存在 另一個 BOM 表主件 或是 BOM 表的用料已經算成成本
升級硬體,沒提升效能....這是錯的
調校軟體,提升效能......這也是錯的

正解是

升級硬體,調校軟體
然後收硬體加軟體的錢謝謝謝謝謝謝
鐵殼心 iT邦高手 1 級 ‧ 2011-01-21 19:02:19 檢舉
antijava提到:
升級硬體,調校軟體

當一台20萬的伺服器, 效能跑輸一台2萬的PC時...工程師是無法收尾的.
Albert iT邦高手 1 級 ‧ 2011-01-21 19:57:46 檢舉
@@ 建議使用資料倉儲與資料清理的技巧 @@
OLTP - OLAP 分離
這是好事
但是滾成本到 OLAP ?? 好像很扯
月平均成本 40萬比 不會超過 4分鐘啦
Albert iT邦高手 1 級 ‧ 2011-01-21 20:04:26 檢舉
anti-java 大阿哥英明

teck-sin 大阿哥英明

正黃旗 恭親王 亞伯王 敬賀
raytracy iT邦大神 1 級 ‧ 2011-01-21 23:28:19 檢舉
antijava提到:
正解是
升級硬體,調校軟體

+10,000 .....Antijava 神準英明....

為什麼樣要這做? 因為台灣普遍存在「無形體 = 無價值」的觀念, 即便 IT 部門可以認同你的顧問功力而付費, 但財務和稽核部門卻總是可以挑骨頭, 讓 IT 下不了台. 所以, 我們必須利用「有形的硬體」當成一個媒介, 表面上讓不懂的人覺得「買了這個東西以後, 真的有改善耶!」, 但骨子裡卻是趁機進去解決無形的軟體或設定問題, 堪稱一石二鳥之計.
raytracy iT邦大神 1 級 ‧ 2011-01-21 23:28:26 檢舉
simon581923提到:

那....Ray超人老大最後是.....?
(搬桌、擺椅、泡茶...請...Ray老大請講...)

跟客戶對賭, 我只遇過兩種狀況: 一種是客戶不敢賭所以不成案, 另一種則是我賭贏了大部分 (不一定是全贏, 但至少可以贏回 65% 以上的賭金), 目前還沒有遇過成案後是我全輸的.....

我不只跟客戶賭 IT 效能, 有時也會賭經營績效, 例如: 導入 XXX 系統之後, 保證 ROI 可以達到 ??%, 庫存降低 ??%....等等, 例如: 某連鎖體系的總管理處, 我們花將近兩年時間, 幫她做完 BPR, 導入 ERP 之後, 將每月庫存量從原本 30% 降低到 5% 以下, 每年省下數千萬週轉金. 賭金是: 上線後第一年省下的錢歸我們團隊....

上面是賭大的, 也有賭比較小的, 例如: 每月電費/通訊費可以節省 xxx 元, 每月人事可以省 xxx 人, OPEX 可以降低多少, EBITDA 可以提高多少....; 我們曾經讓一個企業集團, 原本需要雇用 40+ 位初級會計人員, 降至只需要 3 個人就可以處理相同的事務量, 賭金同樣是: 第一年省下的錢歸我們....

最近的小案子, 則是讓一個集團, 把 23 台伺服主機, 縮減成兩台並導入 HA 功能. 效益是: 省下電費, 空調費, 硬體維護費, 機房空間成本, UPS 採購成本, 同時將「系統可用率」從原本的 95% 提高到 99.99%.

我曾以三百萬成本創立 ISP 事業, 最後以三億賣掉, 也曾在資本額 6x 億的集團擔任高階主管, 最後以 7x 億賣掉 (但這個案子太大, 我只有敲邊鼓的份, 沒我的功勞).....不過我自己前兩年太大意敗在外匯期貨, 目前還負債千萬, 正努力爬起中....

ps. 上面所指的團隊, 並非是固定的成員, 我們會視接到案件的特性, 再來決定這個案子, 要徵招哪些專長的人進來當成員? 過程有點像老牌電視影集「虎膽妙算」的片頭橋段....一年接的案件也不多, 頂多一兩件大案, 外加一些快速結案的零碎小案....
raytracy提到:
某連鎖體系的總管理處, 我們花將近兩年時間, 幫她做完 BPR, 導入 ERP 之後, 將每月庫存量從原本 30% 降低到 5% 以下, 每年省下數千萬週轉金. 賭金是: 上線後第一年省下的錢歸我們團隊


能說服客戶這點,實在很厲害拍手

以前提過類似的政府補助計畫
評審委員最愛講的詞(我都聽到會背了無言)
就是
BPR - 商業流程要先改變
配合流程的改變,組織(人事)要跟著變動
組織(人事)功能的改變,最後才是IT系統的配合
如此龐大規模的改變
你如何證明ROI, Income增加, 成本降低
都全然是你IT系統導入的功勞

講到這裡我就倒
鐵殼心 iT邦高手 1 級 ‧ 2011-01-22 00:00:08 檢舉
raytracy提到:
目前還負債千萬, 正努力爬起中....

太陽大...幫你找到一個奮鬥努力的參考目標抱抱
raytracy iT邦大神 1 級 ‧ 2011-01-22 00:12:39 檢舉
player提到:
資料表要正規化啦

正規化 Normalize 當然是一個可能的選項, 但這也要看他是做甚麼事情?.....
有時, 過度的正規化反而會降低速度; 此時反而需要適時的「反正規化」(Denormalize)....

Data warehouse/Data Mining 就是一種: 過度正規化反而可能會影響效能的常見情境.
這通常需要反覆測試才能得到最佳的結果. 但是, 大部分的程式設計師都沒耐心做這種測試....

最好是由專業的資料庫管理師(DBA)來做, 可惜的是, 台灣似乎很少有部門會配置 DBA 的職位...
raytracy iT邦大神 1 級 ‧ 2011-01-22 00:33:11 檢舉
antijava提到:
BPR - 商業流程要先改變
配合流程的改變,組織(人事)要跟著變動
組織(人事)功能的改變,最後才是IT系統的配合
如此龐大規模的改變
你如何證明ROI, Income增加, 成本降低
都全然是你IT系統導入的功勞
所以, 不能拿 IT 當成主題來切入.

我們通常都先直接接觸總經理, 從企業營運績效的角度來分析, 先找出營運的病因, 再訂下績效目標, 而 IT 只是為了達到目標的一種方法 (當然, 這中間要有合乎邏輯的串接).

如果經營團隊對我們的方法有疑慮, 我們會反過來問: 那麼你們覺得, 應該採取甚麼方法 (不一定是用 IT 科技), 才能達到你們訂出來的目標? 雙方一定會有討論/折衝, 最終的方法不見得是我們想用的, 但是我們自己也會評估, 是否能用客戶要求的方法, 達成要求的績效目標? 如果沒把握, 就再協商/遊說, 否則就退場.

其實, 遊說是一件非常漫長的過程, 佈線經常要長達半年到一年以上的時間. 而且不能只跟總經理一個人說, 必須上至董事會, 下至一級主管, 每一個關節都要去說服. 直到所有部門主管都相信: 這樣做真的有很大的機會可以達成目標, 此時再向董事會提案, 背後挾帶總經理和經營團隊的支持, 成功機率就很大.

當然, 也有很極端的案例, 是董事長希望引進我們團隊, 藉由外來團隊進行 BPR/ERP 的旗號, 來強迫其他董事就範於董事長的經營理念. 在這種情境下, 我們必須充分配合董事長的意念來行動, 反而不是去說服他....

喔對了, 我們團隊裡面, 原本就有專門寫經濟部科專計畫的行銷人才, 我們也實際拿過科專計畫補助案...
鐵殼心 iT邦高手 1 級 ‧ 2011-01-22 08:07:48 檢舉
raytracy提到:
台灣似乎很少有部門會配置 DBA 的職位...

這個職位通常都是MIS兼的...謝謝
cmwang iT邦大師 1 級 ‧ 2011-01-22 08:30:48 檢舉
raytracy提到:
台灣似乎很少有部門會配置 DBA 的職位...


22K都能省則省了,哪會有DBA的預算啊,不過東省西省沒省多少,倒是一出包就不知要吐多少出去就是了.....
raytracy提到:
其實, 遊說是一件非常漫長的過程, 佈線經常要長達半年到一年以上的時間. 而且不能只跟總經理一個人說, 必須上至董事會, 下至一級主管,


讚
pantc328 iT邦研究生 1 級 ‧ 2011-01-22 13:46:29 檢舉
台灣的資訊產業.
是一標,二標,三標...10000萬,1000萬.100萬..到廠商都無利可圖.
開給資訊人員是150k/m.....最後派22k/m的小朋友去駐點.
台灣IT廠商要生存就要偷拐騙搶...
每一家公司都說實力多堅強.開發多少個案例...其實只有不到25%上線
每一位程設師要找工作都寫你做過多少Case...有的人一年還開發10幾個Case,其實他只是Team member而已.

很多失敗的案例不如怪廠商.你本身公司的人也沒實力,也不花大錢請有經驗的人.很多大公司都請一些學歷高的人來打嘴砲而已.

總之事後諸葛人人會.出事後在去檢討別人為什麼這樣做
bizpro iT邦大師 1 級 ‧ 2011-01-22 15:38:52 檢舉
raytracy提到:
有時, 過度的正規化反而會降低速度; 此時反而需要適時的「反正規化」(Denormalize)....

這是普遍台灣軟體業的說法, 如果不能達到完全正規化, 表示商業邏輯的理解有誤,或需要改進, 應該再仔細研究商業邏輯, 如果商業邏輯有錯, 未來的某個時間點就會出紕漏, 也會讓系統的擴展成為夢靨, 也就是antijava的老圖的第三張. 成本也成了第八章, 如果客戶願意付, 你贏, 如果是你自己付, 只好倒閉了.
去年, 我去解一個完全沒有程式碼的ERP系統(公司已倒閉)的效能問題, 解了, 正是正規化不全的問題導至系統必需不斷的以JOIN來頭痛醫頭, 腳痛醫腳.
Albert iT邦高手 1 級 ‧ 2011-01-22 19:36:14 檢舉
bizpro提到:
正是正規化不全的問題導至系統必需不斷的以JOIN來頭痛醫頭, 腳痛醫腳.

完全正規化之後才會有不斷的以JOIN來頭痛醫頭
這是跟銀行改為櫃員制反正規化很像
不需到處 join
出貨單 有的欄位 原則上除了串接欄位 不應該出現在 出貨單項次資料表中
這是正規化的基本教義
因此表頭與表身單一檔案都無法了解其內容需要一堆 join
因此有很多笨笨的 國際級軟體跟很多土產軟體
會讓你百萬筆 join 百萬筆
準備讓你每次等幾十分鐘才有你的資料
bizpro iT邦大師 1 級 ‧ 2011-01-22 20:37:29 檢舉
albertachen提到:
不需到處 join

因為高度正規化, 所以才需要join, 這是毋庸置疑的, 我所指的並不是說join是錯的, 我的意思是, 因為沒有高度正規化, 逼使後來的工程師只能不斷的以非正化的資料表解決"眼前"的問題, 因此就產生了很多的"不必要"的join, 而且是以複合欄位join, 但是卻又不能理解使用複合欄位的索引, 或因為疊床架屋的設計導致"後來"的工程師懼怕修正前人的問題, 所以問題就不斷地擴大. 處理不了了, 只好就放棄, 問題是, 問題不會消失, 但人可以走開, 最後就成了商業上的大問題了.

我想大家都知道, 資料庫的運算是很"昂貴的", 但是, 更昂貴的是"人", 而完全正規化是減低這個最昂貴的成本-人的惰性與錯誤-最好的方法. 我的主張是認為, 要盡全力以商業邏輯來處理問題, 而不是丟給資料庫, 完全正規化提供MVC的資料庫端的低耦合的機會, 雖然會在初期增加成本, 卻是系統得以在長期發展中得到最好的效能與最低的成本.

我實在很難相信正規化會是系統發展的"絆腳石", 很可惜, 我不時會聽到這樣的論調, 我想這論調是源自於惰性吧, 不願在商業邏輯上絞盡腦汁, 一股腦的把問題丟給資料庫.
bizpro iT邦大師 1 級 ‧ 2011-01-22 23:56:31 檢舉
有些主張denormalization的人是著眼在效能(主要是select), 其實這是很有風險的, 因為在(delete, insert, update)上會增加成本的, 尤其當工程師素質不齊或文件化不詳細, 這個成本往往成為不定時炸彈, 當系統規格改變後, 當初的denormalization可能會成為抓不到的"問題".
raytracy iT邦大神 1 級 ‧ 2011-01-23 00:30:31 檢舉
bizpro 兄說得沒有錯, Normalization 確實是應該要徹底執行的工作, 而且市面上有很多寫軟體的人, 都沒有確實地去做.

不過前面也提到, 在特定的情境中, 如果 Real-time Query 需求量和效能要求遠大於 Modify 的時候(例如: Data Warehouse/Data Mart), 適時的 Denormalization 是增加 Query 效能的選項之一. 原意並不是指在任何情況都要使用 Denormalize.

一個好的軟體設計人員, 應該懂得靈活運用各種方法, 來提升軟體的品質, 而不是只抓著一個已知的技巧, 就完全不去鑽研其他的方法. 其實上面討論的重點是在, 軟體設計人員到底瞭不瞭解軟體品質的意義? 以及有沒有追尋高品質的動力? 我在台灣的市場似乎看不到這樣的動力存在....
鐵殼心 iT邦高手 1 級 ‧ 2011-01-23 09:32:10 檢舉
RAY大 與 BIZ兄
我想關鍵問題是在於 先求有 在求好 這個迷思.
借海棉大的圖用用

客戶知道自己要什麼卻說不出來
業務聽不懂客戶真正的需求
工程師(程式設計師)寫不出來客戶要的東西
寫出來的東西驗收不了, 然後再改規格, 反反覆覆東改西改.
最後客戶花大錢買不到想要的東西, 程式設計是被罵到臭頭, 賠上公司的信譽.

亞伯王就會講

你怎麼一天到晚無法收尾

你是規劃又施工
施工又規劃
又是代工
又是品牌
乾脆
不要玩軟體好不好
鐵殼心 iT邦高手 1 級 ‧ 2011-01-23 09:42:59 檢舉
或者把簡單的尋貓啟事變成電影海報之類的...


bizpro iT邦大師 1 級 ‧ 2011-01-23 10:48:00 檢舉
Ray兄說的"在特定的情境中"應該指的是"東方思維"吧, 西方思維裏的時間與空間和東方是有些出入的, 原本中國人說的"名不正則言不順"應該類似西方的"命名空間"的觀念, 這跟軟體扯上什麼關係? 品質的好壞在一開始就決定了, 正規化的用意就是正名, 正物件與事件的名, 如果這個名都無法正, 往後的"言"-也就是寫程式-如何順? 只是很可惜, 明明有"正路"可走, 卻有很多的工程師要用各種workaround來"證明"自己的不凡.

Ray兄的經歷與專業著實令人欽佩, 我想Ray兄說的是現實, 我也看到了很多這些現實, 也許這些特殊的denormalization(我翻作"降正規化")例子可以開個版來討論討論, 就我所知道的, 取值(fetch), 聚合(aggregation), 和延展(extend)是降正規化的主要模式, 其中的取值, 例如產品的單價存入訂購明細中, 並不一定是降正規化, 因為單價可能會變, 有人主張以多對多關聯一個售價檔來避免取值, 那就要用商業邏輯來判斷了; 聚合的情況,例如,發生在訂單的總額來自訂單明細的金額加總, 是否降正規化是有爭議的, 因為第三正規化是指非主鍵欄位的依賴性, 因此有人的論點是, 訂單總額是來自另一個資料表的欄位, 並未違反第三正規化, 我的看法是從低耦合的角度, 即使可以爭論為不違反第三正規化, 但卻提昇了兩個資料表的耦合度, 讓insert, delete, update變得複雜, 這是不好的設計, 反過來說, 不這樣做, 讓data warehousing或reporting變得艱困(select上), 對我來說, 我是使用了這個欄位, 因為我找到了一個存在很久的商業邏輯, 使得這個欄位的存在有其獨立性, 這個商業邏輯存在真實的環境中很久了, 只是很多人忽略了. 這也是我為什麼會認為要從商業邏輯上找出真相, 而非資料庫.
bizpro iT邦大師 1 級 ‧ 2011-01-23 10:53:02 檢舉
tecksin提到:
客戶知道自己要什麼卻說不出來
業務聽不懂客戶真正的需求
工程師(程式設計師)寫不出來客戶要的東西

這三種人都不是關鍵人物, 都只是穿著國王的新衣的人, 要像the Matrix一樣, 找出keyman(key persons): 掌控商業邏輯的人. 像Ray兄所說的, 要"佈線"很久, 佈線是為了找到"key persons"
賽門 iT邦超人 1 級 ‧ 2011-01-23 12:27:06 檢舉
bizpro提到:
要"佈線"很久, 佈線是為了找到"key persons"

是要派臥底嗎?

疑?!我們是在談什麼呢? Ray超人老大是在為國安局工作的嗎? 空
raytracy iT邦大神 1 級 ‧ 2011-01-23 13:19:47 檢舉
bizpro提到:
使得這個欄位的存在有其獨立性, 這個商業邏輯存在真實的環境中很久了, 只是很多人忽略了. 這也是我為什麼會認為要從商業邏輯上找出真相, 而非資料庫.
我非常贊同 bizpro 兄的這個論點, 軟體人員如果不能了解真正的商業邏輯, 或是邏輯背後的意義, 在整個開發過程中, 就只能被客戶的聯絡窗口牽著鼻子走, 很可能多走很多冤枉路...

bizpro 兄的經驗豐富, 小弟在這方面還落後許多, 只能擷取一些道聽塗說的看法來濫竽充數; 大家應該要好好咀嚼 bizpro 兄的觀念, 找出真正對的做法. Do the right thing 要比 Do the things right 更優先....
鐵殼心 iT邦高手 1 級 ‧ 2011-01-23 13:31:47 檢舉
bizpro提到:
因為我找到了一個存在很久的商業邏輯, 使得這個欄位的存在有其獨立性, 這個商業邏輯存在真實的環境中很久了, 只是很多人忽略了. 這也是我為什麼會認為要從商業邏輯上找出真相, 而非資料庫.

很早之前...應該是上個世紀的事情吧, 有個前輩也是這麼樣跟我說的.
只是我當時年輕不懂事, 沒有悟道.
player iT邦大師 1 級 ‧ 2011-01-23 23:01:33 檢舉
要看效能耗在哪邊?
原始資料要正規化
但是如果涉及到展示層
會出現頻繁的join或排序的話
則要反正規化
把欄位預先展開在一個Table裡(在View裡做join, 可能也會是效能的盲點)
這樣才可能改善join所需的龐大比較時間
如果不要把資料只想成一層的話, 有時可以用空間換取時間

DBA與SA缺一不可
如果是大型系統的建置的話
不過
如果要省錢的話
那就別管效能了
能用與正確性優先
bizpro iT邦大師 1 級 ‧ 2011-01-24 23:06:31 檢舉
raytracy提到:
Do the right thing 要比 Do the things right 更優先....

這是管理學的精華, 謝謝.
bizpro iT邦大師 1 級 ‧ 2011-01-24 23:29:40 檢舉
哈, 上一個世紀囉. 我還在回憶這古老的道理. 上個世紀, 我的一位印度的老師上資料庫的課程時, 她說The Devil is in denormalization, seducing you. 魔鬼就在降正規化中, 引誘著你.
Albert iT邦高手 1 級 ‧ 2011-01-25 00:03:47 檢舉
不談正規
談談關連串接

你是土產天王久久神功法
文字串 單別+單號 串接法

還是單據內碼序號快快串接法
player iT邦大師 1 級 ‧ 2011-01-25 13:47:21 檢舉
你說的不就是正規化
該做的事嗎?

1 個回答

14
pantc328
iT邦研究生 1 級 ‧ 2011-01-21 16:15:07

演算法跟資料結構問題

Albert iT邦高手 1 級 ‧ 2011-01-21 20:09:04 檢舉

pan tc 328 大阿哥 英明

正黃旗 恭親王 亞伯王 敬上

Albert iT邦高手 1 級 ‧ 2011-01-22 15:04:12 檢舉

資料不一定要在SP裡算.
資料庫裡跑的邏輯跟AP跑的邏輯不一樣.
有時將資料撈到前端算完後再寫回資料庫可能會比較快.

直接加減可能比較慢 ..
直接讀取 後搬出去 再加減 再搬回來 再寫入 可能必較快 ..
難怪 SAP 10分鐘 比較慢
JDE 400 分鐘 比較快
10分鐘 比較慢倒閉
400 分鐘 比較快倒閉
用 Stored Procedure 提升運算 系統真的比較慢 被換掉

Albert iT邦高手 1 級 ‧ 2011-01-22 19:23:01 檢舉

有些好幾十層你用這種方式絕對掛.
你不如將關連變成XML的樹狀結構去算比較快.

這是土產軟體 好好笑的設計
明明是工單的製程有10個
就變成 10階
真是好好笑的設計
一般 BOM 表超過 5/6階的
幾乎都是製程編成 BOM 不是真的有 10 階的 BOM

我要發表回答

立即登入回答