Introduction

Prisma tables are just like any normal database table, they define how my objects should look like. But instead of having to define these tables both in the frontend and in the backend, with prisma I can simply define the tables ones in schema.prisma file.

Overview
Where do I define a Table?
How does a Table look like?
Enums to define a range of possible values
Prisma Tables as Typescript Type to avoid double definition
Relations between tables just like with SQL

Where do I define a Table?

The prisma tables or enums can be easily defined in the schema.prisma file.

prisma/schema.prisma

I just can add them right below the datasource db.

datasource db {}
 
// define model here

Here I can learn more about the Prisma Schema.


How does a Table look like?

Since I’m already familiar with SQL-Databases, these Prisma Tables feel pretty familiar. Many of the SQL syntaxes look the same or at least pretty similar. Its recommended, that each table should contain these values:

model Ticket {
  id        String       @id @default(cuid())
  createdAt DateTime     @default(now())
  updatedAt DateTime     @updatedAt
}

Any further values can be customized,

likes     Int 
title     String
content   String       @db.VarChar(1024)   // Max 1024 Chars

Here I will link more examples:


Enums

Enums allow me to predefine a range of possible values, this makes sure that I won’t assign a wrong value by mistake. Also typescript recognizes this enum and will let me know, if I should happen to assign a wrong one.

enum TicketStatus {
  OPEN
  IN_PROGRESS
  DONE
}

Once defined, I can easily link my Table with the enum and even define a default value in case no other has been choosen:

model Ticket {
  status    TicketStatus @default(OPEN)
}

Prisma Tables as Typescript Type

Once defined, the database and even Next.js will be able to handle the prisma table. I can simply just import the table anywhere in my project and use it’s definition as typescript type:

import { Ticket } from "@/generated/prisma/client";
 
type TicketItemProps = {
  ticket: Ticket;  // Use as type
};

Limitation - Big Application

For smaller and medium size application I can skip the typescript file and only relay on the prisma.schema. However once an application reaches a certain size, its no longer recommended to blindly trust the prisma schema. In big applications there are many changes happening to tables after the schema creating and therefore I cant be sure anymore whether this schema is accurate or not - often I should go back to ts types then.

prisma.schema -> db (many modifications) -> queries -> UI

Alternative - TS Type

An possible alternative to prisma schemas are typescript types, wich I could place for example here:

src/features/ticket/types.tsx

A possible typescript type definition could look like this one:

export type TicketStatus = "OPEN" | "DONE" | "IN_PROGRESS";
 
export type Ticket = {
  id: string;
  title: string;
  content: string;
  status: TicketStatus;
};

Relations

Just like with normal SQL, it’s also possible to define different relations between the tables. Some of the relevant options are:

  • One-to-one
  • One-to-many
  • Many-to-many

More details can be found here:


Conclusion

Prisma Tables or Models or Schemas are a incredible way of defining the database objects. Not only does it look almost like SQL-Tables, but it also acts like a typescript type. This is amazing - no longer do I need to define two objects, one in the backend and one in the frontend. Also the pain of creating a rest api is obsolete and this is gonna save me so much time.