Navicat 部落格

資料庫或應用程式是自訂函式的最好地方嗎? 2020 年 5 月 6 日,由 Robert Gravelle 撰寫

要決定是在資料庫中還是在應用程式程式碼中建立函式可能是一項很艱巨的工作。在很多情況下,你不會意識到自己作出了錯誤的選擇,直到麻煩出現在面前為止。更糟糕的是,許多開發人員的決定都是因為他們熟悉 SQL 還是應用程式編碼!一個較好的方法是依靠技術的優勢來決定。在今天的文章中,我們將詳細分析選擇使用者定義函式(user-defined function,簡稱 UDF)還是在應用程式端的函式的決策過程。

資料庫的能力!

資料庫對某些事情可以表現得很好,但有些事情會遇到困難。像預存程序、函式是用 SQL 撰寫的。因此,它們在 SQL 表現出眾的工作上有出色表現。這是此類工作的清單,以及為什麼最好用 SQL 完成這些工作,而不是用應用程式程式碼:

  • 聯結:在應用程式程式碼中,這可能需要複雜的陣列操作
  • 篩選資料(也就是 WHERE 子句):在程式碼中,這可能需要在清單中大量插入和刪除項目
  • 選取欄:同樣,在應用程式程式碼中,這可能需要複雜的陣列操作
  • 彙總函式:在應用程式程式碼中,這可能需要陣列來儲存數值和複雜的切換案例
  • 外部索引鍵完整性:在應用程式程式碼中,這可能需要在插入之前進行查詢,並假設沒有人會取存應用程式外部的資料
  • 主索引鍵完整性:在應用程式程式碼中,這也可能需要在插入之前進行查詢,並假設沒有人會取存應用程式外部的資料

如在不依賴 SQL 的情況下嘗試執行上述任何操作,這會無可避免地要編寫大量程式碼並降低效率,更可能要偵錯和維護更多程式碼,以及令應用程式的效能變差。

另一方面,DBMS 不能勝任複雜的程序處理。那就是應用程式程式碼的領域。這是整合開發環境(Integrated Development Environment,簡稱 IDE)的偵錯功能(例如 VS Code 或 Eclipse)遠遠優勝於資料庫開發環境中的任何功能的重要原因。

個案研究

The Sakila 範例資料庫是作為一種學習工具而開發的,並已在整個資料庫社群中廣泛共用。這是一個 MySQL 資料庫,其中包含與虛構的影片出租商店有關的許多資料表、檢視、預存程序和函式。stocker_in_stock 是這些函式其之一。它是一個 UDF,接受 stock_id 輸入參數,並傳回一個布林值顯示該影片是否有庫存。

這是 Navicat Premium 的函式設計器中的 ventory_in_stock 函式定義:

inventory_in_stock_function (120K)

讓我們快速執行它以了解其工作原理。

按一下「執行」按鈕將彈出一個對話方塊,以接受輸入參數:

inventory_in_stock_param_dialog (14K)

結果如下:

inventory_in_stock_results (18K)

結果值為 1 表示該電影有庫存。

現在,如果我們使用應用程式中的函式取代該函式會怎麼樣呢。它需要呼叫資料庫兩次以執行 SQL 陳述式。這將導致額外的網路流量,並要在應用程式內維護 SQL。通常,這是一個不當的做法,因為它將資料庫和應用程式程式碼混合在一起。

總結

在今天的文章中,我們了解到應該將自訂函式程式碼放置在最能受益於該技術優勢的地方:在需要複雜程序處理時放置在應用程式中,以及在需要 SQL 時放置在資料庫中。

有興趣了解有關Navicat Premium 的更多資訊嗎?你可以免費試用 14 天!

Navicat 文章
頻道記錄
分享
部落格封存檔