uuid v7の指定方法

model User {
  id   String @id @default(uuid()) // defaults to 4
  name String
}

model User {
  id   String @id @default(uuid(4)) // same as above, but explicit
  name String
}

model User {
  id   String @id @default(uuid(7)) // will use UUIDv7 instead of UUIDv4
  name String
}

https://github.com/prisma/prisma/releases/tag/5.18.0

Prismaでリレーションを定義する

https://www.prisma.io/docs/orm/prisma-schema/data-model/relations/one-to-one-relations

https://zenn.dev/tsucchiiinoko/articles/f222dbbfa23325

1対多, 1対1

/**
 * User Entity
 */
model User {
  userId   String   @id @default(uuid(7)) // UUID v7を指定する。
  email     String   @unique
  name      String
  createdAt DateTime @default(now())
  messages  Message[] // User:Message = 1:N の関係を持つ。
  userProfile UserProfile? // User:UserProfile = 1:1 の関係を持つ。(Optional)
}

// メッセージの送信者を特定するための列挙型
enum Sender {
  USER
  AI
}

/** 
  * Message Entity

  - メッセージの送信者を特定するために、userIdを外部キーとして持つ。
  - User:Message = 1:N の関係を持つ。
 */ 
model Message {
  messageId String @id @default(uuid(7)) // UUID v7を指定する。
  userId    String
  user      User   @relation(fields: [userId], references: [userId])
  sender    Sender // メッセージの送信者を特定するための列挙型
  content   String
  createdAt DateTime @default(now())
}


/** 
  * UserProfile Entity

  - ユーザーの基本情報を収集するフォームのエンティティ。
  - User:UserInfoForm = 1:1 の関係を持つ。
 */ 

model UserProfile {
  userProfileId String @id @default(uuid(7))

  userId String @unique // User:UserProfile = 1:1 の関係を持つ。
  user User @relation(fields: [userId], references: [userId])

  createdAt DateTime @default(now())
}

PrismaでEnumを定義する

enum Role {
  USER
  ADMIN
}

model User {
  id    Int   @id @default(autoincrement())
  name  String
  role  Role  @default(USER)
}

Prismaでこれやりたい集📝

https://zenn.dev/yuji6523/articles/7d93ea5f4ebbe8

Prismaでnot null📝

Prismaでは、スキーマファイル内でフィールドの型を定義する際、型の後ろに疑問符（?）を付けなければ、そのフィールドは必須（NOT NULL）として扱われます。
つまり、次のように定義するだけで NOT NULL のカラムが作成されます。

model User {
  id   Int    @id @default(autoincrement())
  name String // NOT NULL カラム
}

逆に、name String? とすれば、そのカラムはNULLを許容するようになります。

また、既存テーブルに新たな必須カラム（NOT NULL）を追加する場合、既存のレコードに対して値が設定されていないとマイグレーションエラーとなるため、デフォルト値を設定するか、生成されるマイグレーションSQLを編集して対応する必要があります。

PrismaでIndexを付与する📝

Prismaでは、データベースのパフォーマンスを向上させるためにインデックスを簡単に設定することができます。インデックスはクエリの実行速度を向上させる重要な機能です。

基本的なインデックスの付与方法

Prismaでインデックスを設定するには、主に@@index属性を使用します。この属性はモデルレベルで適用され、単一カラムと複数カラムの両方のインデックスをサポートしています[1][3]。

単一カラムのインデックス

model Post {
  id        Int      @id @default(autoincrement())
  title     String
  content   String?
  
  @@index([title])
}

複数カラムのインデックス（複合インデックス）

model Post {
  id        Int      @id @default(autoincrement())
  title     String
  content   String?
  
  @@index([title, content])
}

この例では、titleとcontentフィールドに対して複合インデックスを作成しています[1][3][4]。

インデックス属性の設定オプション

@@index属性には以下のような引数を指定できます[1]:

• fields: インデックス対象のフィールドを指定する必須引数
• name: インデックスの名前を設定（省略可能）
• map: 名前が明示的に指定されていない場合のインデックス名の命名規則を定義
• length: String型とBytes型の値のインデックスサイズを指定（MySQLのみ）
• sort: インデックスエントリの保存順序を指定（Asc/Desc）
• type: PostgreSQLでのみ使用可能で、BTree以外のアクセスメソッドをサポート
• clustered: インデックスがクラスター化されているかどうかを設定（SQL Serverのみ）
• ops: PostgreSQLでのみサポートされ、特定のインデックスタイプの演算子を定義

名前付きインデックスの例

model User {
  id    Int    @id @default(autoincrement())
  email String
  phone String
  
  @@index([email, phone], name: "email_phone")
}

この例では、emailとphoneフィールドに対して"email_phone"という名前の複合インデックスを作成しています[4]。

ユニーク制約とインデックス

SQLデータベースでは、ユニーク制約を定義すると、対応するユニークインデックスも自動的に作成されます[1]。つまり、@unique属性が付与されたカラムには自動的にインデックスも割り当てられます。

model User {
  id    Int    @id @default(autoincrement())
  email String @unique
  phone String
}

複合ユニーク制約を設定する場合は、以下のように記述します：

model User {
  id        Int    @id @default(autoincrement())
  email     String
  phone     String
  
  @@unique([email, phone], name: "unique_email_phone")
}

インデックスの適用

スキーマにインデックスを追加した後は、マイグレーションを実行して実際のデータベースに反映させる必要があります[1][8]：

# npm
npx prisma migrate dev --name add_some_indexes

# pnpm
pnpm dlx prisma migrate dev --name add_some_indexes

このコマンドを実行すると、Prismaは新しいマイグレーションファイルを作成し、そこにインデックス作成のSQLスクリプトが含まれます[1]。

まとめ

Prismaでインデックスを付与するには、主に@@index属性を使用します。
単一カラムと複数カラムの両方のインデックスをサポートしており、様々な設定オプションを通じてデータベース固有の機能も活用できます。
インデックスを適切に設定することで、クエリのパフォーマンスを大幅に向上させることができます。

Prismaの文字列型の種類

Prismaでは、文字列データを扱うための型として主に以下の種類があります。

基本的な文字列型

Prismaの基本的な文字列型はStringです。これはデータベースによって異なる型にマッピングされます[8]。例えば：

• PostgreSQLではtext型にマッピングされます[7][8]
• MySQLではvarchar(191)型にマッピングされます[17]

文字列型のバリエーション

データベース固有の型を指定したい場合は、@db属性を使用して以下のように指定できます：

PostgreSQLの場合

• @db.Text - 大量のテキストを格納できる型（最大1GBまで）[5]
• @db.VarChar(n) - 可変長の文字列（例：@db.VarChar(255)）[5]

その他のデータベース固有の型

データベースによって、さまざまな文字列型をサポートしています[15][16]。

文字列配列型

Prismaでは、データベースがネイティブにサポートしている場合、文字列の配列も使用できます[12]：

tags String[]

文字列型の属性

文字列型には以下のような属性を付けることができます：

• @id - 主キーとして使用[8]
• @unique - 一意の値を強制[4]
• @default("値") - デフォルト値を設定[8]
• ? - オプショナル（null許容）を表す[10]

例

model User {
  id        String   @id @default(cuid())
  name      String?  // オプショナルな文字列
  email     String   @unique
  bio       String   @db.Text // 大量のテキスト
  username  String   @db.VarChar(50) // 最大50文字
  tags      String[] // 文字列の配列（サポートされている場合）
}

Prismaでは、これらの型を使い分けることで、データベースの特性を活かしながら型安全なアプリケーション開発が可能になります[6][7]。

Prismaで、Columnの順序を指定するには？

Prisma ORMでは 列の並び順を制御する公式構文はまだ提供されておらず、
生成される DDL は「最初にテーブルを作成したときの定義順」か「既存 DB の順序 (db pull / introspection の結果)」に従います。
実行時のクエリは列順に依存しないため、現状は 見た目の並びを変えたい場合だけ手作業で DDL を編集するのが定石です。

1-1 Prisma で順序を指定できない理由

• Prisma スキーマには @map などのマッピング属性はありますが 「この列を他の列の前後に置く」ための属性は存在しません ([Stack Overflow][1], [Reddit][2])
• 公式 Issue でも「DB 側の列順をソースオブトゥルースとし、スキーマの並び替えは行わない方針」と明言されています ([GitHub][3])

結論: Prisma だけで列順を固定することはできません。

1-2 どうしても順序を変えたい場合のワークフロー

1. ドラフトマイグレーションを生成

   npx prisma migrate dev --create-only
   

2. 生成された migration.sql を開き、PostgreSQL なら

   ALTER TABLE "User"
     ALTER COLUMN "email" DROP DEFAULT,
     ALTER COLUMN "email" SET DATA TYPE varchar(320),
     -- ↓ 独自に追記
     ALTER TABLE "User"
       ALTER COLUMN "email" SET POSITION 3; -- ※MySQL の AFTER/BODY などに置き換え
   

3. 編集後に適用

   npx prisma migrate dev
   

   Prisma ドキュメントにも「順序変更など Prisma が自動生成しない DDL は手で書いてから適用する」例が示されています ([Prisma][4])

注意: Postgres には ALTER COLUMN … POSITION が無いので、実際には「新規テーブルを作ってコピー→リネーム」などを行います。列順はアプリ動作に影響しないため、可読性に拘らなければマイグレーション編集は不要です。

まとめ

• 列順は Prisma では指定不可。
• 可読性のために並びを変えたい場合は 手動で SQL を編集するしかありません。
• 「ドラフトマイグレーションを生成して手を加える」ワークフローを覚えておくと、Prisma がまだ対応していない DB 機能を安全に取り込めます。

Columnにコメントを追加するには？

列やテーブルにコメントを付けるための仕組みは用意されており、/// ドキュメンテーションコメントといくつかのワークフローを組み合わせると DB レベルの COMMENT ON 句まで生成できます。

1. /// でドキュメンテーションコメントを付与できる！

Prisma スキーマでは /// で始まるコメントを AST に埋め込み、外部ツールが取得できるようになっています ([Prisma][5])

/// ユーザー情報
model User {
  id   Int    @id @default(autoincrement())

  /// メールアドレス (RFC 320chars)
  email String @db.VarChar(320)
}

2. DB レベルの COMMENT ON を自動生成する方法

3. モデルコメントも対応

/// をモデルの先頭につけておけば、上記のいずれの方法でもテーブルコメントとして付与されます ([GitHub][8], [GitHub][8])

まとめ

• 列コメントは /// と previewFeature comments で公式にサポート。
• 既存プロジェクトでは Generator や手書き追記も実用的です。