為何選擇 Prisma ORM？
在本頁中，你將瞭解 Prisma ORM 的動機，以及它與傳統 ORM 和 SQL 查詢構建器等其他資料庫工具的比較。
使用關係型資料庫是應用程式開發中的一個主要瓶頸。除錯 SQL 查詢或複雜的 ORM 物件通常會耗費數小時的開發時間。
Prisma ORM 透過提供清晰且型別安全的 API 來提交資料庫查詢，並返回普通 JavaScript 物件，從而使開發人員能夠輕鬆地理解他們的資料庫查詢。
TLDR
Prisma ORM 的主要目標是提高應用程式開發人員在使用資料庫時的生產力。以下是 Prisma ORM 如何實現這一目標的幾個例子：
- 以物件思維，而不是對映關係資料
- 查詢而非類，以避免複雜的模型物件
- 資料庫和應用程式模型的單一事實來源
- 健康的約束，防止常見的陷阱和反模式
- 一個讓正確的事情變得簡單的抽象（“成功之坑”）
- 型別安全的資料庫查詢，可在編譯時驗證
- 更少的樣板程式碼，讓開發人員專注於應用程式的重要部分
- 程式碼編輯器中的自動補全，無需查閱文件
本頁的其餘部分將討論 Prisma ORM 如何與現有資料庫工具進行比較。
SQL、傳統 ORM 和其他資料庫工具的問題
Node.js 和 TypeScript 生態系統中現有資料庫工具的主要問題是，它們需要在生產力和控制之間做出重大權衡。
原生 SQL：完全控制，低生產力
使用原生 SQL（例如，使用原生 pg 或 mysql Node.js 資料庫驅動程式），你對資料庫操作擁有完全控制權。然而，生產力會受到影響，因為向資料庫傳送純 SQL 字串很麻煩，並且會帶來很多開銷（手動連線處理、重複的樣板程式碼等）。
這種方法的另一個主要問題是你無法獲得查詢結果的型別安全。當然，你可以手動輸入結果，但這需要大量工作，並且每次更改資料庫模式或查詢以保持型別同步時，都需要進行重大重構。
此外，以純字串形式提交 SQL 查詢意味著你無法在編輯器中獲得任何自動補全功能。
SQL 查詢構建器：高控制，中等生產力
一種既能保持高水平控制又能提高生產力的常見解決方案是使用 SQL 查詢構建器（例如 knex.js）。這類工具提供了一種程式設計抽象來構造 SQL 查詢。
SQL 查詢構建器最大的缺點是，應用程式開發人員仍然需要用 SQL 的術語來思考他們的資料。這帶來了將關係資料轉換為物件的認知和實際成本。另一個問題是，如果你不完全清楚自己在 SQL 查詢中正在做什麼，就很容易自食其果。
傳統 ORM：較少控制，更高生產力
傳統 ORM 透過允許你將應用程式模型定義為類來抽象 SQL，這些類對映到資料庫中的表。
“物件關係對映器”（ORM）旨在彌合程式設計師的朋友（物件）和資料庫的原語（關係）之間的鴻溝。這些不同模型的原因既有文化上的，也有功能上的：程式設計師喜歡物件，因為它們封裝了執行程式中單個事物的狀態。資料庫喜歡關係，因為它們更適合整個資料集的約束和整個資料集的有效訪問模式。
然後，你可以透過呼叫模型類例項上的方法來讀寫資料。
這方便得多，也更接近開發人員思考資料時的心智模型。那麼，有什麼問題呢？
ORM 代表著一個泥潭，開始時一切順利，但隨著時間推移變得越來越複雜，不久便將使用者困在一個沒有明確界限、沒有明確勝利條件、沒有明確退出策略的承諾中。
作為一名應用程式開發人員，你對資料的心理模型是物件。而 SQL 中資料的心理模型則是表。
這兩種不同資料表示形式之間的差異通常被稱為物件關係阻抗不匹配。物件關係阻抗不匹配也是許多開發人員不喜歡使用傳統 ORM 的主要原因。
例如，考慮每種方法如何組織資料和處理關係：
- 關係型資料庫：資料通常是規範化的（扁平的），並使用外部索引鍵在實體之間進行連結。然後需要對實體進行 JOIN 操作才能體現實際關係。
- 面向物件：物件可以是深層巢狀的結構，你可以簡單地使用點表示法遍歷關係。
這暗示了傳統 ORM 的一個主要陷阱：雖然它們讓你可以看似簡單地使用熟悉的點表示法遍歷關係，但實際上 ORM 在底層生成了 SQL JOIN，這些 JOIN 操作成本高昂，可能大幅降低應用程式的速度（其中一個症狀是 n+1 問題）。
總而言之：傳統 ORM 的吸引力在於它們承諾抽象關係模型，並純粹從物件的角度思考資料。儘管這個前提很好，但它基於一個錯誤的假設，即關係資料可以輕易地對映到物件，這導致了許多複雜性和陷阱。
應用程式開發人員應該關注資料——而不是 SQL
儘管 SQL 在 1970 年代（！）就已開發出來，但它以令人印象深刻的方式經受住了時間的考驗。然而，隨著開發工具的進步和現代化，值得思考的是，SQL 是否真的是應用程式開發人員最佳的抽象工具？
畢竟，開發人員應該只關心實現某個功能所需的資料，而不是花費時間去弄清楚複雜的 SQL 查詢，或為了滿足需求而調整查詢結果。
在應用程式開發中，還有另一個反對 SQL 的論點。如果你確切知道自己在做什麼，SQL 的強大功能可能是一種福氣，但其複雜性也可能是一種詛咒。即使是經驗豐富的 SQL 使用者，也難以預料到許多 反模式 和陷阱，這往往會以效能和數小時的除錯時間為代價。
開發人員應該能夠請求他們需要的資料，而不必擔心在 SQL 查詢中“做正確的事情”。他們應該使用一個能為他們做出正確決定的抽象。這可能意味著該抽象會施加某些“健康的”約束，以防止開發人員犯錯。
Prisma ORM 提高開發人員的生產力
Prisma ORM 的主要目標是提高應用程式開發人員在使用資料庫時的生產力。再次考慮生產力和控制之間的權衡，這就是 Prisma ORM 的定位：
