※ 引述《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)