PTT職涯區 / Soft_Job (軟體人)

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

看板Soft_Job (軟體人)作者 (ing)時間11年前 (2013/07/01 01:10), 編輯推噓8(8推 0噓 24→)
留言32則, 13人參與, 最新討論串6/9 (看更多)
: → 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
推
07/01 01:19, , 1F
我遇到的情況相反..AP server太弱 只好靠DB server
07/01 01:19, 1F
推
07/01 01:40, , 2F
都是很極端的做法，不同元件就負責不同功用，全塞在一起
07/01 01:40, 2F
→
07/01 01:40, , 3F
當然就是悲劇了
07/01 01:40, 3F
→
07/01 01:41, , 4F
一個公司可以讓你碰到三個這樣的人，老闆還很高興?
07/01 01:41, 4F
→
07/01 01:41, , 5F
猜想這老闆應該是種香焦的，只出的起香焦
07/01 01:41, 5F
→
07/01 01:56, , 6F
client、AP server：喂!DB 你是好了沒啊? 我閒到發慌耶...
07/01 01:56, 6F
→
07/01 02:56, , 7F
問題是通常不會是 AP 去寫 SP 是 DBA 去寫 SP 跟規劃
07/01 02:56, 7F
→
07/01 02:57, , 8F
有 DBA 還會讓 AP 去寫 AP 跟做出 DBA 不爽的 DB 結構，這
07/01 02:57, 8F
→
07/01 02:57, , 9F
DBA 已經形同虛設了吧。XDDDD
07/01 02:57, 9F
→
07/01 02:57, , 10F
讓 AP 去寫 SP
07/01 02:57, 10F
推
07/01 09:24, , 11F
管db不寫ap，寫ap不能碰db
07/01 09:24, 11F
→
07/01 12:19, , 12F
我也會寫SP，不過我不喜歡把所有的東西都塞到DB裡
07/01 12:19, 12F
→
07/01 12:25, , 13F
太複雜的功能用SP不太好寫
07/01 12:25, 13F
→
07/01 12:25, , 14F
另外我個人認為CURSOR效能比較差，我會用另外其他方法來做
07/01 12:25, 14F
推
07/01 14:19, , 15F
全部塞到DB的SP去,就犠牲掉了應用層的scalability了;運算的
07/01 14:19, 15F
→
07/01 14:20, , 16F
瓶頸全部擠在DB上,日後要擴大應用層的運算能力就知死了
07/01 14:20, 16F
→
07/01 14:22, , 17F
不過這種[本末倒置]的做法的確有可能發生,例如這個案子要求
07/01 14:22, 17F
→
07/01 14:23, , 18F
運算上的kpi,但開發人員實作的方法達不到kpi的要求,開始會弄
07/01 14:23, 18F
→
07/01 14:24, , 19F
出一堆不合邏輯的怪步數,這種將原本應用層該負責的運算塞到
07/01 14:24, 19F
→
07/01 14:24, , 20F
DB的SP去就是一種偷雞步.如果客戶端對系統架構很熟的,這種東
07/01 14:24, 20F
→
07/01 14:25, , 21F
西在提案階段就被退件了,根本不可能接受還讓它進實作階段
07/01 14:25, 21F
推
07/01 16:12, , 22F
可能是都一個人包吧....= =
07/01 16:12, 22F
→
07/01 23:02, , 23F
非常同意DB Server的效能是很貴的~
07/01 23:02, 23F
推
07/01 23:16, , 24F
web service也可以拿來救援一下
07/01 23:16, 24F
推
07/02 06:22, , 25F
原來是這樣 SP是DB當Server用
07/02 06:22, 25F
→
07/02 23:28, , 26F
簡單的說就是老闆根本沒概念也沒肩膀 所以
07/02 23:28, 26F
→
07/02 23:29, , 27F
聽到programmer說這樣可以做 就笑開懷 叫所有人全力配合
07/02 23:29, 27F
→
07/02 23:29, , 28F
久而久之DBA就覺得管他去死 反正爛掉剛好而已...
07/02 23:29, 28F
→
07/02 23:30, , 29F
之前還叫DBA幫忙查程式是哪一段沒有close connection ..
07/02 23:30, 29F
→
07/02 23:38, , 30F
說到香蕉 今天水果店老闆推荐一種叫雞蛋蕉 聽說不錯吃喔
07/02 23:38, 30F
推
07/04 01:07, , 31F
表格運算，在DB跑怎樣都比AP專業跑的快，但邏輯的部份AP
07/04 01:07, 31F
→
07/04 01:07, , 32F
怎樣都比DB靈活，這部份得各取所需
07/04 01:07, 32F
‣ 更多 iFEELing 的文章
文章代碼(AID): #1Hq6Pogn (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 6 之 9 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共9篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 iFEELing 的文章
文章代碼(AID): #1Hq6Pogn (Soft_Job)