Make your DB schema as restrictive as possible for easier migrations

Hello there friends. Welcome to June I am thinking about Postgres and Prisma and that sort of thing a lot lately because I'm working on my website and doing that sort of thing and one tip that I have for you if you ever do database sort of things is try to make sorry to make your data as.

As restrictive as possible. Early on as as you're trying to make things. So like make things if you're like, I don't know if there should be a required field or not make it required. If you're this is an enum but we could have this we could have a lot of different values for this potentially have the fewest number of values possible to get you to the next phase.

The reason is because it's a lot easier to later do a migration.That expands the permissive venous of that schema than going the other direction because when you go the other direction, you have to find all of the data rows that don't go into the new schema and update those so that they they fit.

So, for example, if you have a first name field and you decide to make it optional first and then after you have a bunch of users you come in later and you decide no no this first name field needs to.Be required. Well, now you have to first go and update all of the usernames to be like unknown or something before you can do that schema update.

And so yeah, just try to when you're starting a new project or when you're yeah, I guess not even a new project but when you're adding a new model or something like that try to be as restrictive as possible early and then you can loosen things up later when you have more context and you know, what makes more sense.

So yeah, hopefully that's helpful and interesting. IIt's this is just personally affected me because I I was really loose at the start of this project and then I had to tighten things up and it's kind of annoying. So anyway, I hope that's interesting helpful. Ah, but a nice day.