Establish Table Relationships

[00:00:00]
>> Speaker 1: Now we're going to set up the relationships, so let's do that To set the relationships, we'll say export const userRelations The way this works is we use this relations helper

[00:00:00]
It's pretty simple We want to use relations on the user's table, and then we get this callback function where we can destructure some things that give us access to what type of relationship this is

[00:00:00]
For the users, we know a user can have many habits, and that's the only relationship it has So we want to get the many helper right here Then what we want to do is return an object like this and say, "Hey, for habits, I want to have many habits." This is basically saying that if you query the user, you now get a new field called habits, which is going to be all the habits that belong to the user

[00:00:00]
And we know how to do that because habits reference the user It's kind of denormalizing it a little bit Then we'll do it the other way on the other side of the relationship

[00:00:00]
Let's say habits relations This one has two different types of relationships for different things: a one-to-one and a many-to-many We're going to use both of those

[00:00:00]
For the one-to-many, habits are the many side, and users are the one side For the user, you can only have one user for a habit, so we'll use one and say it's a user table

[00:00:00]
We'll define the relationships where the fields linking a user and a habit are on the habits.user_id field, referencing the users.id What this means is on the habits table, we want to add a new field called user that can only have one user

[00:00:00]
You know which user by the habits.user_id field that should match the user.id field This is how it finds our relationship We want to set a relationship on habits and make a new field

[00:00:00]
If you look at habits, we don't have a field called user, just user_id We want to be able to say habits.user and get back a user object This is saying we want to make a new field called user

[00:00:00]
It's a one-sided relationship where habits are the many side and users are the one side, meaning habits can have one user The matching fields are on the habit side: habits.user_id referring to user.id

[00:00:00]
For the many side, we have entries because a habit can have many entries This is super easy: we'll say many entries The same goes for habit tags: habits can have many habit tags

[00:00:00]
We'll set up entries relations as a many-to-one because an entry can only belong to one habit We'll add a new field to entries called habit, which is one of habits

[00:00:00]
The fields will be entries.habit_id, referencing habits.id For tags, this is a many-to-many relationship because one tag can have many habits and a habit can have many tags

[00:00:00]
We'll set up the habit tags relationship For the habit tags table, it's essentially a one-to-one relation because you can only have one habit and one tag pair

[00:00:00]
This joint table allows us to connect a single habit to a single tag, which is a best practice for many-to-many relationships We'll reference the habits table using the habit_tags.habit_id field, which references the habits.id

[00:00:00]
We'll do the same for tags, using habit_tags.tag_id referencing the tags.id It's important to be careful with these relationships If you use an invalid column name, Drizzle won't automatically catch it

[00:00:00]
This is something developers often struggle with - making sure the relationships are correctly defined While it might seem verbose to write these relation helper methods, they provide a way to define how related objects should be populated and accessed

[00:00:00]
Other ORMs like Prisma handle this differently, but Drizzle gives you explicit control over these relationships As for whether to break the schema into separate files, there's no hard rule

[00:00:00]
For smaller projects, keeping everything in one file is fine For larger projects with many tables, breaking it out can improve readability Just be cautious of potential circular dependencies when splitting schemas across files.