Question

I am mapping out a very small database and have some design questions about good design practice. Let’s say I have a Restaurant table, and a restaurant has an Address and an Open Time and a Special Day (MTuWThF)

1. A restaurant will only have one address. I’m tempted to put all
   the associated address fields (Street 1, Street 2, City, State, ZIP)
   into the Restaurant table, but I think breaking it out into its
   own table will allow me to create an Address class within my
   domain objects and, if I want to change the way Addresses are done
   later it may make it easier. I’ve typically thought of 1:1 tables as
   bad practice…

2. An Open Time is an HH:MM representation of when a restaurant opens. I don’t need a full DateTime because the Date portion would be wasted. Is a varchar the best way to represent this, then?

3. There is a Special Day (Monday, Tuesday, etc…) I want to store in my schema as well. Does it make sense to just store this day as a varchar or would anyone recommend creating a reference table (kinda like an enum) with Sunday (1), Monday (2)…etc. and use an int to store which day the Special Day falls on?

   **DayOfWeek**
   Id (int)
   Day (varchar)
   
   **Service**
   Id (int)
   RestaurantId (int)
   DayOfWeekId (int)
   ...
   

Thanks guys!

Answer 1

A lot of what you’re asking boils down to how you think it would work best for your needs. Hopefully some of what I say below will be useful.

One-to-one tables aren’t necessarily bad, and in fact, they’re sometimes used to partition data to make retrieval more efficient. For example, if there are 10 fields that you use a lot and 25 more that are relatively large that you don’t use as much, you can put the 25 in another one-to-one table so that the database engine doesn’t have to futz around with them when you’re snagging the 10 fields you use all the time.

In your case, I could go either way. Unless you’re an experienced developer, I’d suggest just putting the address fields into the restaurant table. You don’t want to overthink it. Trying to get too fancy will likely only cause you to waste a lot of time and effort on something that might never happen. Besides, if you do decide to change the data in your address table later, honestly, just running a few ALTER TABLE commands is not going to be any easier on an address table versus just running them directly on your restaurant table. In short, keep it simple unless you know that you’re going to be changing it later.

Regarding times, some database systems actually support a TIME type (with a date). For example, here is MySQL’s documentation on it. Another option is to just use a standard DATETIME, but with a specific date as a reference point. For example, January 1 1970. So if you want to store 3:30pm, store it as ‘1970-01-01 15:30:00’. You can perform whatever formatting on the back end that you want to display just the time part. One of the advantages of this is that if you want to eventually use those times in any kind of calculation, it’s much easier having them stored as DATETIMEs than as VARCHARs. For example, if you want to know how long a restaurant is open on a particular day, you can use something like:

SELECT `closetime` - `opentime` AS "openhours" FROM `restaurants`;

As for storing a day of the week, honestly I’d just make it a TINYINT and store 1 (Sunday) through 7 (Saturday). MySQL has built-in functions that return 1 through 7 as a day of week, and I think most databases are the same on that. It would make it much easier in queries such as the one below to determine if a given date is a “special” day:

SELECT * FROM `restaurants` where DAYOFWEEK(?) = `special_day`

Most scripting languages would let you compile that as a prepared query and then you could just pipe dates in very efficiently.

Hopefully this helps and gives you some considerations. Good luck with your project, dates and times can get really hairy to deal with, especially when you start getting into timespans and such.