Model design for Online Food order app

I have been trying to develop online food order application. I have taken the concept of zomato.com where a user or say owner registers his/her restaurant. After adding the restaurant, an executive from the company will fix a meeting with him/her, take pictures and menu of his/her restaurant by himself/herself or ask him/her to mail it. Long story short an admin will list all the menus in his/her restaurant.

Note: A user can have multiple restaurant. A restaurant has multiple menu items.

For such process flow and structure alike Zomato, will this database design fit well? Is my database designed perfectly deeming best practices?

If i have missed any part, please pitch your thought and idea.

restaurant/models.py

```
class Restaurant(models.Model):
OPEN = 1
CLOSED = 2

OPENING_STATUS = (
(OPEN, 'open'),
(CLOSED, 'closed'),
)

BREAKFAST = 1
LAUNCH = 2
DINNER = 3
DELIVERY = 4
CAFE = 5
LUXURY = 6
NIGHT = 7

FEATURE_CHOICES = (
(BREAKFAST, 'breakfast'),
(LAUNCH, 'launch'),
(DINNER, 'dinner'),
(DELIVERY, 'delivery'),
(CAFE, 'cafe'),
(LUXURY, 'luxury dining'),
(NIGHT, 'night life'),
)

MONDAY = 1
TUESDAY = 2
WEDNESDAY = 3
THURSDAY = 4
FRIDAY = 5
SATURDAY = 6
SUNDAY = 7

TIMING_CHOICES = (
(MONDAY, 'monday'),
(TUESDAY, 'tuesday'),
(WEDNESDAY, 'wednesday'),
(THURSDAY, 'thursday'),
(FRIDAY, 'friday'),
(SATURDAY, 'saturday'),
(SUNDAY, 'sunday'),
)
user = models.ForeignKey(User)
restaurant_name = models.CharField(max_length=150, db_index=True)
slug = models.SlugField(max_length=150, db_index=True)
address = models.CharField(max_length=100)
city = models.CharField(max_length=100)
restaurant_phone_number = models.PositiveIntegerField()
restaurant_email = models.EmailField(blank=True, null=True)
owner_email = models.Email

I'm not totally familiar with Zomato, but I assume it's like any review site for restaurants.

I'll state my assumptions from the start, they might be useful for envisioning the models.

• Restaurants have menus (lunch, dinner, drinks)

• Menus have food/drink items (what people would be ordering)

You also appear to be mapping out properties of restaurants as well.

• Owners have restaurants (for handling chains)

• Restaurants can be open/closed depending on the day of the week (closed on Sundays, weekends only)

• Restaurants may open/close at different times depending on the day of the week (dinner only on Mon-Thurs, no breakfast on Sunday)

With all of those assumptions stated, you might see some issues within your models.

-
You should not use an IntegerField for a list of items.

They inherently only allow a single selection, which makes it impossible to mark something like the days of the week that a restaurant is open. You should use a ManyToMany field for storing things like this.

-
You should separate out your hours of operation information from the Restaurant model.

Right now it's impossible to set different open/close times for different days of the week. While you could just create 12 new fields (14 total - 2 existing) for storing open/close times for each day, you could also store it as a separate model. This allows you to add additional metadata to it in the future.

For logging the hours that a restaurant is open, you are going to want a dedicated model for it. You probably want to include (at minimum) the following fields

• Opening time - The time that the restaurant opens on that day.

• Close time - The time that they close at. This may be before the open time.

• Day of week - An integer field representing the day of the week that the time is for.

• Restaurant - The restaurant to apply this for, of course.

Your FEATURE_STATUS and OPENING_CHOICES lists clearly represent choices which may have multiple options. You are currently only allowing a single choice for both of these (likely in other places as well), when you probably want to allow multiple choices. The easy solution here would be to create something similar to your Category model, but connect it with a ManyToMany field instead of a ForeignKey.

StackExchange Code Review Q#138736, answer score: 2