Prisma最新版本引入了改進的資料模型語法。它摒棄了Prisma過去在資料庫佈局方面許多主觀性決策,為開發者提供了更多控制權。

在過去的幾個月裡,我們與社群合作,為Prisma定義了改進的資料模型規範。這個新版本名為資料模型 v1.1,已在今天的穩定版中釋出。請查閱這裡的文件。
一種更靈活的資料建模方法
一個資料模型是每個Prisma專案的基礎。它作為底層資料庫模式的基礎。
當前的資料模型在資料庫佈局方面存在主觀性,例如關係、表/列的命名或系統欄位。新的資料模型語法消除了許多限制,使開發者能更好地控制其模式。
對資料庫佈局有更多控制權
新資料模型語法支援以下幾項功能:
- 指定關係是使用關係表還是外部索引鍵
- 模型/欄位名稱可以與底層表/列的名稱不同
- 使用任何欄位作為
id欄位並“自帶ID” - 使用任何欄位作為
createdAt或updatedAt欄位
更簡單的遷移和改進的內省
在之前的Prisma版本中,開發者必須透過設定PRISMA_CONFIG中的migrations標誌來決定Prisma是否為他們執行資料庫遷移。
最新版本的Prisma已移除migrations標誌,這意味著開發者現在可以隨時手動遷移資料庫或使用Prisma進行遷移。
我們還在現有資料庫的內省方面投入了大量精力,為使用Prisma處理舊資料庫或需要在某個時間點執行手動遷移的開發者提供了流暢的工作流程。
改進後的資料模型語法有哪些新功能?
將模型和欄位名稱對映到底層表和列
使用舊的資料模型語法,表和列的命名總是與您的資料模型中的模型和欄位完全一致。使用新的@db指令,您可以控制底層資料庫中表和列的名稱。
在這種情況下,底層表將被稱為user,列將被稱為full_name。
決定關係如何在資料庫模式中表示
舊的資料模型對資料庫模式中的關係有主觀性:它們總是被表示為關係表。
一方面,這使得將任何現有關係輕鬆遷移到多對多關係成為可能,而無需額外工作。然而,這種靈活性可能需要付出效能代價,因為關係表的查詢成本通常更高。
雖然1:1和1:n關係現在可以透過外部索引鍵表示,但m:n關係將繼續以關係表的形式表示。
透過新的資料模型,開發者可以完全控制在底層資料庫中表達關係的方式。有兩種選擇:
- 透過內聯引用(即外部索引鍵)表示關係
- 透過關係表表示關係
這裡是一個包含兩種關係(一種是內聯,另一種使用關係表)的示例
對於內聯關係,@relation(link: INLINE)指令的放置位置決定了外部索引鍵儲存在關係的哪一端,在此示例中它儲存在User表中。
使用任何欄位作為id、createdAt或updatedAt
在舊的資料模型中,如果開發者想自動生成唯一ID或追蹤記錄建立/上次更新的時間,則需要使用保留欄位。
透過新的@id、@createdAt和@updatedAt指令,現在可以將此功能新增到模型的任何欄位。
更靈活的ID
當前的資料模型始終使用CUIDs來為資料庫記錄生成和儲存全域性唯一ID。資料模型v1.1現在可以維護自定義ID,並使用其他ID型別(例如整數、序列或UUIDs)。
新資料模型語法入門
我們為您準備了兩個簡短教程,以探索新的資料模型
- 選項 A:將舊的Prisma專案升級到新的資料模型語法
- 選項 B:從頭開始使用新的資料模型語法
有關更詳細的教程和使用現有資料庫的入門說明,請訪問文件。
先決條件:安裝最新的Prisma CLI
要安裝最新版本的Prisma CLI,請執行
透過Docker執行Prisma時,您需要將其Docker映象升級到
1.31。
選項 A:從舊版Prisma升級
升級現有Prisma專案時,只需執行prisma introspect即可生成使用新語法的資料模型。具體過程在以下章節和此影片中透過示例進行了描述
1. 舊資料模型設定
假設您已經有一個使用(舊)資料模型的正在執行的Prisma專案。
使用舊資料模型時,Prisma會在底層資料庫中建立以下表
使用者個人資料帖子類別_CategoryToPost_PostToUser_ProfileToUser_RelayId
每個關係都透過一個關係表表示。_RelayId表用於透過其ID標識任何記錄。使用舊的資料模型語法,這些是Prisma做出的決策,無法繞過。
2. 升級您的Prisma伺服器
在用於部署Prisma伺服器的Docker Compose檔案中,請確保對prismagraphql/prisma映象使用最新的1.31 Prisma版本。例如
現在升級正在執行的Prisma伺服器
3. 透過內省生成新的資料模型
如果您現在執行prisma deploy,您的Prisma CLI將丟擲錯誤,因為您正嘗試將舊語法的資料模型部署到已更新的Prisma伺服器上。
解決這些錯誤的最簡單方法是透過內省生成一個使用新語法編寫的資料模型。在您的prisma.yml檔案所在的目錄中執行以下命令
這將內省您的資料庫並生成另一個使用新語法的資料模型,名為datamodel-TIMESTAMP.prisma(例如datamodel-1554394432089.prisma)。對於上述示例,將生成以下資料模型
4. 部署新的資料模型
最後一步是刪除舊的datamodel.prisma檔案,並將您生成的資料模型重新命名為datamodel.prisma(以便prisma.yml中的datamodel屬性指向使用新語法的生成檔案)。
完成此操作後,您可以執行
5. 最佳化您的資料庫模式
因為內省沒有改變您的資料庫佈局,所有關係仍然表示為關係表。如果您想了解如何將舊的1:1和1:n關係遷移為使用外部索引鍵,請查閱這裡的文件。
選項 B:從頭開始
在瞭解如何升級現有Prisma專案後,我們現在將引導您完成一個從頭開始的簡單設定。
1. 建立一個新的Prisma專案
讓我們從設定一個新的Prisma專案開始
在互動式嚮導中,選擇以下內容
- 選擇 建立新資料庫
- 選擇 PostgreSQL(如果您願意,也可以選擇MySQL)
- 選擇您偏好語言的客戶端(可選,因為我們不會使用該客戶端)
在透過Docker啟動Prisma伺服器和資料庫之前,請為您的資料庫啟用埠對映。這將允許您稍後使用本地資料庫客戶端(例如Postico或TablePlus)連線到資料庫。
在生成的docker-compose.yml中,取消註釋資料庫Docker映象配置中的以下行
2. 定義資料模型
讓我們定義一個利用新Prisma功能的資料模型。開啟datamodel.prisma並將內容替換為以下程式碼
以下是此資料模型定義的一些重要部分
- 每個模型都使用
@db指令對映到一個表,該表的名稱與模型名稱相同但為小寫。 - 存在以下關係
- 1:1
User和Profile之間 - 1:n
User和Post之間 - n:m
Post和Category之間
- 1:1
User和Profile之間的1:1關係在User模型上用@relation(link: INLINE)進行了註解。這意味著如果關係存在,資料庫中的user記錄將引用一個profile記錄(因為profile欄位不是必需的,所以關係可能為NULL)。INLINE的替代方案是TABLE,在這種情況下,Prisma將透過專用的關係表跟蹤關係。User和Post之間的1:n關係透過post表的author列在關係中進行內聯跟蹤,即@relation(link: INLINE)指令推斷在Post模型的author欄位上。Post和Category之間的n:m關係透過一個名為PostToCategory的專用關係表進行跟蹤。該關係表是資料模型的一部分,並使用@relationTable指令進行註解。- 每個模型都有一個使用
@id指令註解的id欄位。 - 對於
User模型,資料庫透過使用@createdAt指令註解的欄位自動跟蹤記錄的建立時間。 - 對於
Post模型,資料庫透過使用@createdAt和@updatedAt指令註解的欄位自動跟蹤記錄的建立時間和更新時間。
3. 部署資料模型
下一步,Prisma會將此資料模型對映到底層資料庫
Category
表
索引
category_pkeyBTREETRUEidPost
表
索引
post_pkeyBTREETRUEidPostToCategory
表
索引
post_to_category_AB_uniqueBTREETRUEcategory,postpost_to_category_BBTREEFALSEpostProfile
表
索引
profile_pkeyBTREETRUEidUser
表
索引
user_pkeyBTREETRUEidhello-datamodel$dev.user.email._UNIQUEBTREETRUEemail4. 在Prisma Admin中檢視和編輯資料
從現在開始,如果您想以程式設計方式訪問資料庫中的資料,可以使用Prisma客戶端。在下文中,我們將重點介紹如何使用Prisma Admin與資料進行互動。
要訪問Prisma Admin中的資料,您需要導航到Prisma專案的Admin端點:https://:4466/_admin

分享您的反饋和想法
雖然新的資料模型語法已經包含了社群要求的許多功能,但我們仍然看到進一步改進它的機會。例如,資料模型尚未提供多列索引和多型關係。
我們目前正在開發一種新的資料建模語言,它將是當前使用的SDL的變體。
我們很想聽聽您對新資料模型的看法。請透過在反饋倉庫中提交問題分享您的反饋,或加入Spectrum上的討論。
不要錯過下一篇文章!
訂閱Prisma新聞通訊