今天的內容主要來介紹你為何要使用 primsa ORM 當作你的開發工具。

Goal

在說服你使用 prisma 之前先簡單介紹 prisma 希望達到的開發目標是什麼吧～，先簡單列出以下的內容：

• Thinking in objects ：以物件的角度思考 model ，而不是如何 mapping 到 SQL。
• Queries not classes ：避免複雜的 model 結構。
• Healthy constraints ：防止常見陷阱和反模式的約束。
• An abstraction that makes the right thing easy ：讓開發者可以更專注在應用程式，而非思考 SQL mapping 這件事。
• Type-safe database queries : 可以在編譯的時候就去 validated code。
• Less boilerplate ：以往我們用傳統 SQL 會需要處理許多重複且繁瑣的內容，例如 connection pool 的控制等等。

SQL vs ORMs vs database tool

我們在發應用程式會用到 database 的時候，尤其實在 nodejs 或是 typescript 的生態中，肯定都會遇到一個問題就是，需要衡量，SQL 的控制程度，與生產力這件事。

備註: SQL 控制程度代表你需要控制多少原生 SQL 語法。

圖片來源

Raw SQL (Full Control, Low Productivity)

如果你是使用 Raw SQL 你必須要完完全全的使用 SQL 的所有語法甚至是對應的 operations 等等，但相對的你的生產力會大大下降，原因是你需要傳送諸多的 SQL strings 去執行 DB 操作，期間你會遇到的麻煩會是，你需要處理許多重複的內容，例如手動的 connection 或是一些 Repetitive Boilerplate 內容。

同時你會遇到的內外一件問題就是完全沒有任何的 type 可以使用，雖然你可以手動自己添加 type 到你的應用層，但這也產生大量的時間成本去處理這件事情，甚至如果 type 定錯，你無法錯確保程式碼在編譯期間，或是執行期間不會有任何的問題，而且如果 SQL 要做 migration 很容易會忘記去修改 type 內容。

因此使用 Raw SQL 去開發你的應用層是，並不會有任何 autocompletion 得內容來提升你的生產效率。

SQL Query Builders ( High Control, Medium Productivity )

由於 raw SQL 衍生的問題同時在考量生產力的因素下，SQL builder 就出現了，最常見的 builder 大概就是 knexjs 為主，SQL builder 提供建制 SQL 指令時抽象化的一個工具，解決的是傳統 raw SQL 不能 auto generate 的問題，但因為 SQL builders 本質上還是需要寫 SQL 指令，一樣讓開發者不能好好專心在應用程上，還是需要考量 SQL 映射這件事，所以如果對 SQL 指令不熟，同時也不理解 SQL builders 將資料轉換成物件的過程，容易讓開發者完全不知道自己在 SQL 查詢中做了哪些事情，這也是另外一種開發的心智負擔。

ORM ( Less Control, Better Productivity )

ORM 本質上就是提供一個界面去以及物件的資料結構去抽象化 SQL 的 table，但因為 ORM 本身的資料結構跟 SQL 的資料結構就有很大的差異，ORM是以物件形式去關聯你需要的內容，但 SQL 是透過 join 的方式去關聯 table 的關係，也因為兩者有極大的差異，所以在一開始介紹 ORM 的時候才會提出 ORM 很多時候要克服的是能否兼容原生 SQL 功能，原因就在於兩者的資料結構不一的關係，但筆者認為作為一個開法者，很多時候我們其實更應該專注於有沒有正確拿到資料，以及是否拿到這些資料做到需求等等，而非需要花大量的時間去思考 SQL 之間的語法問題，但還是有原生 SQL 之令的好處就是可以用來驗證應用程式是否如預期的換取資料等等。

但 ORM 也並不是萬能的，雖然他大大的簡化使用 SQL 的門檻，但如果使用不當，能易發生效能問題，也或者是資料關聯錯誤等等的因素，還有一個就是常見的 n + 1 問題，這邊筆者簡單說明一下 n + 1 的錯誤。

N + 1

隨便舉一個例子，假設有一個 books 的 models 跟 author 的 models ，一本書都對應著一個作者，那這時如果我們需要查詢所有書本中對應的作者是誰，很多時候我們在開發時會下意識地寫出以下的 code ，先做一個迴圈拿到 authorid ，再根據 authorid 去查詢相關的這者內容，但這樣的 SQL 的問題就是，如果你的 books 越來越多那你就要多查詢幾次 ( n ) ，然後再查詢你要的內容 (1) ，這樣的 SQL 查詢是有很大的效能問題的。

取而代之的是我們應該不管 books 有多少本，也不會影響我們查詢的次數，解法其實有很多種，簡單舉一個就是可以透過 join 的方式，如此一來你的 SQL 查詢只會有兩次而已 ( 拿整個 books table 去關聯 authors)。

其實還有很多 ORM 在實作時會遇到的問題，這部分讀者有興趣可以在自行研究，這邊筆者就不多做說明～

Prisma

所以 prisma 就是折衷 Raw SQL 與 ORM 出現的問題。

簡化資料模型

• Prisma ORM 允許開發者使用物件來思考和定義數據，而不是直接操作表格。
• 簡化了資料模型，使得開發者可以專注於業務邏輯而不用擔心複雜的 SQL 查詢。

提供類型安全的查詢接口

• Prisma 提供了一個類型安全的 API 來提交資料庫查詢，傳回普通的 JavaScript 物件。
• 使得開發者能夠在編譯時驗證資料庫查詢，減少錯誤。

減少冗餘程式碼

• Prisma 降低了建立和維護資料庫對應的工作量。
• 開發者可以更快實現功能，而不需要花時間在資料庫配置上。

單一資料來源

• Prisma 為應用程式模型和資料庫模型提供單一的定義來源。
• 這簡化了資料模型管理，使得不同部分保持一致。

圖片來源

小結

那到底該用 ORM 還是 raw SQL 我覺得也沒有一定的答案，各有優缺點，可以根據不同的團隊或是專案架構去考量～以上就是今天的內容～理論部分大致上結束明天開始就是大家最期待的實作部分了，我們明天見～

大家如果有問題可以來小弟的群組討論～

✅ 前端社群 ：
https://lihi3.cc/kBe0Y