在閱讀本文之前，請勿使用 Prisma ORM！

想像一下混亂，您在NeonDB 中創建一個具有0.5GB 存儲空間的免費數據庫，然後想，“很好，我將使用免費套餐進行測試” 。然後，幾個小時後，收到了致命的電子郵件：「您的儲存空間已被消耗！」。哇，你什麼意思？連椅子都沒有熱起來！答案是什麼呢？我使用了輝煌的 Prisma ORM，為了改進，我全天運行了幾次遷移，只是對架構進行建模。

讓我們了解發生了什麼，當然，為什麼有時好的舊 SQL 仍然要好一千倍。

首先你需要了解自己的背景。我正在錄製 CrazyStack 課程 124（我的 Node 和 React 訓練營）。並且可以在沒有 ORM 的情況下使用 postgres 或 mongodb。然而，一名學生在 WhatsApp 上要求我將 Prisma 納入該專案。嘿嘿，我決定要做個實驗。

Prisma ORM：簡單但昂貴

Prisma 是那種看起來很完美的東西。 「我將抽象資料庫查詢，節省時間，這就是新的炒作。」但是，驚喜！天下沒有免費的午餐，而這個蘭戈是以烘烤儲存的形式出現的。我白天運行了遷移，並且neondb的負載很重。而且這甚至不是一個巨大的項目。

Prisma 不僅建立遷移，還留下一些額外的表和日誌作為獎勵。如果您像我一樣正在測試事物並左右運行遷移，那麼這份禮物最終來自希臘語。

Prisma 非常好，但在儲存方面，牠喜歡潑出去：

1. 輪次遷移：每次我運行遷移時，Prisma 都會建立並儲存新的遷移。每個都有自己的元資料、日誌和表格小包。

2. 成倍增加的日誌：為了確保不會出現問題（或在出現問題時讓您的生活更輕鬆），Prisma 會記錄詳細的日誌。但這些日誌會不斷積累，而且由於我不是「無限」銀行，它們很快就會成為一個問題。

3. 使用輔助表重載：除了遷移之外，Prisma 還建立額外的表來追蹤各種事物，特別是在關聯式資料庫中，例如 Postgres。

最後，這個看似簡化生活的神奇工具最後吃掉了我的免費NeonDB。

SQL「釘子上」：為什麼少即是多

這就是古老的 SQL 方法的用武之地。是的，Prisma 很棒並且可以節省時間，但有時它只會讓事情變得複雜。讓我們來談談放棄 ORM 並手動編寫查詢的優點：

1. 絕對控制：帳單上沒有什麼意外。您確切地知道每行程式碼在做什麼，並且您不會發現日誌或隱藏表佔用您的空間。

2. No Dead Weight：使用直接 SQL，你寫的就是銀行的內容。沒有元資料、遷移或日誌會降低風險。

3. 更高效能：如果做得好，直接 SQL 會消耗更少的空間和資源。對於像我這樣的免費主義者來說，它是像 NeonDB 這樣的小型銀行的理想選擇。

4. 沒有隱藏業務：沒有從頭開始建立的表或堆積的交易日誌。控制權是你的，而且只屬於你。

這個故事的寓意：

如果您像我一樣喜歡測試工具並進行快速實驗，請在將 Prisma ORM 放入空間有限的資料庫之前三思而後行。 Prisma 是個奇蹟嗎？和。但是，在像 NeonDB 這樣的有限銀行中，這就像開派對時發現你買的啤酒不足以滿足每個人的需求。

有時，「即時」SQL 是最安全的方式，讓您可以精確控制進入資料庫的內容。教訓是：下次，在 0.5GB 儲存體上執行一個又一個遷移之前，我會考慮得更好。

以上是在閱讀本文之前，請勿使用 Prisma ORM！的詳細內容。更多資訊請關注PHP中文網其他相關文章！