推 rushcat:THX!!! 07/03 09:42
※ 引述《rushcat (嗯)》之銘言：
: 推 JoeHorn:維護、除錯的方便，DBMS 異質整合、轉移、備份、更版... 07/01 22:36
: 我也有原PO的疑問
: 可以在DB內一次處理好的事情 為何要拉到AP上來做呢!?
: 目前還沒碰到大型的專案 所以真的不太清楚SP的缺點
: (除了SP真的很難Debug...)
可能很多人只考慮到 Oracle、MS SQL、MySQL、PostgreSQL 這類的 DBMS。
如果是轉移成 MongoDB 這種物件型的 DBMS 呢？
另外，若是新版程式打算導入 ORM ，邏輯依然是必須拉出來處理，不是嗎？
如果讓資料庫存取全部透過 Web Services（或是 class），
原本辛辛苦苦開發出來，放在資料庫裡面的邏輯是不是幾乎等於作白工？
當然，並不是完全不讓資料庫預先處理，
concat 等等的 DBMS 內建 function 該用還是得用。
只是... 放太過複雜的邏輯運算，幾乎可以說是自找麻煩。
我們看到資料，大概可以知道怎麼作邏輯運算。
如果 A 今天開發時，在資料庫裡面建立 function 或 stored procedure；
過了兩年，B 看到資料，自己在程式寫邏輯，A 建立的東西並沒有被善加利用。
這樣可以說是一種資源浪費...
另一方面，程式語言的物件（object）可以包涵資料（data）跟方法（method），
有人選擇開 BLOB 欄位，把整個物件放進去，需要時再拿出來嗎？
: 今天如要UPDATE一筆User資料 可能需要三句SQL指令
: (判斷是否已存在 選擇要Insert Or update)
: 1. SELECT * FROM User WHERE User_Id = @User_Id
: 2. INSERT INTO User VALUES(User_Id, User_Name)
: 3. UPDATE User SET User_Name = @User_Name WHERE User_Id = @User_Id
: 如果全部寫在AP裡 需要二次DB Connection
: 那一般這種狀況會用SP嗎!?
一個 DB connection 可以執行很多次 SQL statements，
你舉的這個例子只需要 transaction，但是.. 可以用同一個 connection。
更何況，很多程式語言有 connection pool 管理能力。
（因為可以用同一個 connection，以下我就不回了.. 因為都不是考量因素）
--
╓╥╥╖╓─╥╖ ╓─╥╖ ╓ ╓╖ ╓─╥╖ ╓─╥╖ ╓╖╓╖
╟╢ ║ ╟╢ ║ ╙╜ ║ ╟╢ ║ ╟╢ ║ ╟╢ ║║╟╢
╟╢ ║ ╟╢ ╟─ ╟─╫╢ ║ ╟╢ ╟─╫╜ ║║╟╢
╟╢ ║ ╟╢ ║ ╓╖ ║ ╟╢ ║ ╟╢ ║ ║ ║║╟╢
╙╨╜ ╙─╨╜ ╙─╨╜ ╙ ╙╜ ╙─╨╜ ╙ ╙╜ ╙╙╨╜
獅子男
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.37.129.214
※ 編輯: JoeHorn 來自: 114.37.129.214 (07/03 00:08)