Re: [閒聊] 開發一定要用MVC架構 ?

[iFEELing (ing)]

: → iFEELing:所以Programmer會覺得SP好用 DBA會覺得X你XX              06/30 20:31
: → TonyQ:我認識的 DBA 都很喜歡寫 SP 討厭 AP 自己寫 SQL 耶..        06/30 22:27
: → TonyQ:看起來這件事情很微妙 XD                                   06/30 22:27
: → TonyQ:反而是 programmer 都很討厭寫 SP                           06/30 22:28
: → TonyQ:我這邊經驗剛好跟 iFEELing 相反                            06/30 22:28
: 推 terrybob:我完全不會寫SP                                         06/30 22:30
: → hSATAC:iFEELing 講的是政治問題，透抽講的是技術問題，不相悖。    06/30 22:42
: 推 CRPKT:有時候是透明度帶來的信心問題, 會想用自己這一側能掌握的    06/30 23:01

唔 我在目前的公司碰過三次 programmer 超愛 SP 的專案

第一次 programmer 說是效能問題

然後把幾乎所有邏輯層通通塞到 SP 裡面

還直接從 SP 裡面發MAIL  , 丟 http request 去其他server傳資料

再讓其他 SERVER 連回 DB 開始撈資料

整個 web UI 只有檢核使用者輸入的功能 然後就通通丟進 DB 算

甚至連月報季報年報也通通在 production DB 上跑 schadule job + SP

接下來其他應用系統就三不五時來抱怨說怎麼 DB 回應那麼慢....

老闆說系統上了就不要去動 想辦法讓線上系統變快

最後是反正有錢好辦事  報效能不足直接換硬體硬幹


第二次是專案的 programmer 以前是寫 delphi 還是什麼鬼的

要他們用 java / c# 寫功能好像怎麼寫都是 sequential 寫法

看到 SP 的語法好像他鄉遇故知 千里故人來 歡喜得很

然後又什麼東西都塞到 SP 裡面去

程式寫的飛快 老闆看了笑呵呵

還好這次跑的東西範圍不大 跟 programmer 喬好不要在線上負載的時候出來搗蛋

線上也沒有太大抱怨


第三次專案又遇上了號稱有效能問題 其實是 progremmer 不想拉資料出來 AP 算

前端一樣是畫好 UI 把所有邏輯都硬塞進 SP 層

這次就直接再開一台 DB 出來 資料抄給他 愛怎麼玩就怎麼玩去吧




所以其實我很不喜歡 AP 邏輯層的東西通通塞到 DB 來跑啊

 DB Server 的資源很貴的

明明提供一堆 AP server 在那邊等著算資料

結果一整櫃的機器畫完 UI 之後就在IDLE

然後大家來搶 DB server 的 cpu 算商業邏輯

然後原本 DB 要做的 sort / merge / hash  等不到 CPU 在那邊 WAIT ....


要你是 DBA 你火不火?


--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 114.35.79.188
推 sharpwolf:我遇到的情況相反..AP server太弱 只好靠DB server
推 avhacker:都是很極端的做法，不同元件就負責不同功用，全塞在一起
→ avhacker:當然就是悲劇了
→ avhacker:一個公司可以讓你碰到三個這樣的人，老闆還很高興?
→ avhacker:猜想這老闆應該是種香焦的，只出的起香焦
→ andymai:client、AP server：喂!DB 你是好了沒啊? 我閒到發慌耶...
→ TonyQ:問題是通常不會是 AP 去寫 SP 是 DBA 去寫 SP 跟規劃
→ TonyQ:有 DBA 還會讓 AP 去寫 AP 跟做出 DBA 不爽的 DB 結構，這
→ TonyQ: DBA 已經形同虛設了吧。XDDDD
→ TonyQ:           讓 AP 去寫 SP
推 Adonisy:管db不寫ap，寫ap不能碰db
→ astt88:我也會寫SP，不過我不喜歡把所有的東西都塞到DB裡
→ astt88:太複雜的功能用SP不太好寫
→ astt88:另外我個人認為CURSOR效能比較差，我會用另外其他方法來做
推 bobju:全部塞到DB的SP去,就犠牲掉了應用層的scalability了;運算的
→ bobju:瓶頸全部擠在DB上,日後要擴大應用層的運算能力就知死了
→ bobju:不過這種[本末倒置]的做法的確有可能發生,例如這個案子要求
→ bobju:運算上的kpi,但開發人員實作的方法達不到kpi的要求,開始會弄
→ bobju:出一堆不合邏輯的怪步數,這種將原本應用層該負責的運算塞到
→ bobju:DB的SP去就是一種偷雞步.如果客戶端對系統架構很熟的,這種東
→ bobju:西在提案階段就被退件了,根本不可能接受還讓它進實作階段
推 f1234518456:可能是都一個人包吧....= =
→ viper9709:非常同意DB Server的效能是很貴的~
推 Ethan96:web service也可以拿來救援一下
推 frankptt:原來是這樣 SP是DB當Server用
→ iFEELing:簡單的說就是老闆根本沒概念也沒肩膀 所以
→ iFEELing:聽到programmer說這樣可以做 就笑開懷 叫所有人全力配合
→ iFEELing:久而久之DBA就覺得管他去死 反正爛掉剛好而已...
→ iFEELing:之前還叫DBA幫忙查程式是哪一段沒有close connection ..
→ iFEELing:說到香蕉 今天水果店老闆推荐一種叫雞蛋蕉 聽說不錯吃喔
推 cwlin0416:表格運算，在DB跑怎樣都比AP專業跑的快，但邏輯的部份AP
→ cwlin0416:怎樣都比DB靈活，這部份得各取所需