1.2 Model Our Business Data

Before we jump straight to the code, I want to give you a small introduction. I want to cover the data entities that we're going to need in order to develop our API. After all, we're gonna consider just a small server that will render plain JSON. We're not gonna handle templates or views or anything like that, just data. And since data is the primary attribute of our application, we're gonna need to make sure that it's thought out at least a little bit. So for a restaurant application I'm consider several entities. The first one I'm gonna call it table. A table is actually very simple to consider because a restaurant has a lot of tables. Each one of them usually has a number, and perhaps a number of seats. That's good for a reservation purposes. If you wanna book a table that has at least a certain number of seats available, you wanna make sure you book it. So it just makes it a lot easier for the owners of the restaurant to run their business. So we're gonna have at least a table entity. As for using the tables in our business, we're also going to consider an order data entity. Each order matches one client visit. Someone comes by the restaurant and books a table right away. The order is what's going to hold all of the information regarding that customer. For example, to keep track of which table he sat on as well as different dishes that he ordered, so that he or his family can enjoy the meal. The order will be the responsible for holding all of that information. Now associated to the order, we're gonna have at least two more. The items and a special entity that I'm going to grey out, it's going to be order items. Let me just put this in italic. Remember that this is not as important as these three. So the items will basically be a dish or something like that. Each dish that the chef can prepare an order by the customer. It's going to reside in an items table. Now the way you relate the items with the order is through this order_items pseudo entity. This will basically be a support table in our database that will hold how many portions of one specific item, or dish, was ordered by the customer. So it will hold a relationship between the order, the item, and, for example, a quantity. If I order two desserts instead of just one, then this is going to come really in handy. Instead of having duplication and stuff like that. So this will be very important as well. At the end, we want to make sure that we create a receipt. The receipt will have more than just the order. I mean of course it will relate to the order, but it will also have other kinds of information. For example, the amount of tip, as well as the amount of tax you had to pay for that meal. Also, you might want to register what kind of method the customer used to pay, either through a credit card, a standard debit card, or plain cash. That kind of information shouldn't really be placed in the order. The order respects the entire process of ordering food and managing its relationship with the table as well. The receipt is kind of a different universe than the actual process, the receipt is there maybe for administrative purposes or for tax paying. Still we're gonna keep it in there. So this will be our main order of business. So we're gonna keep the table, order, items, and order items. So let's just put those in order. Remember the table will be the physical instantiation of a place for the customer to sit and eat his meal. Then the order will have information on the customer, at least just a small detail, maybe, a name and email or something like that. Of course you can extract that kind of information into a separate entity called customer. Let's actually type that in. For this exercise we're gonna keep it simple and really not include this customer information like so. We're gonna shove it into the order. So, as I was saying, the customer info would beyond order as well as for example, when the order was placed, which is actually going to mean when the customer arrived. And then, this is going to have a relationship between the items and the order. This order_items pseudo entity will hold information on how many items of one dish were ordered by this customer. At the end, we're gonna have order related to a receipt. Again this is just for maybe tax paying purposes and for holding specific kinds of information related to perhaps the payment method or a tip that was given, stuff like that. So this is just a general overview that I wanted to provide. This will give you a much broader perspective on the whole picture. With that said, let's jump into the next lesson and learn how to install Rails API.