Data Model

Defining the data model

Project Source Code

Get the project source code below, and follow along with the lesson material.

Download Project Source Code

To set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.

This lesson preview is part of the Fullstack Typescript with TailwindCSS and tRPC Using Modern Features of PostgreSQL course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.

This video is available to students only
Unlock This Course

Get unlimited access to Fullstack Typescript with TailwindCSS and tRPC Using Modern Features of PostgreSQL, plus 70+ \newline books, guides and courses with the \newline Pro subscription.

Thumbnail for the \newline course Fullstack Typescript with TailwindCSS and tRPC Using Modern Features of PostgreSQL

  • [00:00 - 00:12] Okay, so now that we have an idea of what our UI is going to look like, let's think about our data model. The data model is almost the most fundamental part of an app, at least an app like this.

    [00:13 - 00:31] If you're not doing something in some specific field where it's very different, like some scientific computation or something, I think that the data model warrants spending quite a bit of time thinking about because it's difficult to change. Working without database tends to be one of the most stable things in our app.

    [00:32 - 00:39] It's much easier to change code around than it is to change all about data, even though we do work with migration. So we are able to.

    [00:40 - 00:50] It's just harder to do and more error prone and frankly anxiety inducing to me. So I like to try and get the data model as right as I can.

    [00:51 - 01:06] Now luckily, we're in a domain here where we can probably assume that we can use terminology that will work for both the users and the providers and the developers. So we're probably going to have something called a booking and everybody will be able to understand what that means.

    [01:07 - 01:14] But there are still some considerations that we could think of. Like what should a booking be and how do we store it in our database?

    [01:15 - 01:33] Should we maybe divide each day up into say time slots of eight hours, so eight time slots and mark each one as booked or free? Or should we maybe just store a list of bookings and then assume that any time that isn't covered by one of those is free?

    [01:34 - 01:53] And if we do that, should such a booking be fixed in time like fixed in duration or should it be a variable duration? Or perhaps would it be easier for us to do the opposite and store free time in the database so that any time is booked by default unless it's marked as free somehow?

    [01:54 - 02:15] So there are trade-offs to all of these and it depends a lot on what the actual situation is going to be like. For instance, if you're doing something more similar to a gig worker website where most people probably will just have some time now and then but per default won't be available to do something, maybe it's better to do the inverse of what we were looking into.

    [02:16 - 02:30] But for our case, we're probably going to assume that any of our staff is going to be available all of the time unless they are already booked. Then maybe we'll make something that integrates with their own personal calendar so they can enter their holidays or something.

    [02:31 - 02:46] But for this, I think we're going to create something called a booking that will be of variable time and then we're somehow going to have our database help us figure out which times are available and which times are booked. We'll get back to that in a following lesson.