SQL one-to-many relationship for very small 'many' table

Question

I have a 'store_location' table which has a one to many relationship with closing and opening times, which is just to keep track of service hours, and which weekdays those hours are active. So a 'weekdays' column, and 'opening hour', and 'closing hour' if I were to create a new table for it.

But it feels a little unnecessary to have to create a new table just for this. Coming from a NoSQL background, I feel tempted to just create a column "service_times" which is an array of arrays, or array of objects. And what if the 'many' table is even simpler than that, eg I'd also like to do the same with marking public holidays, so i'd have another table just to keep track of closing/opening dates... a 2 column table.

What is best practice here?

Answer 1

The best way to store the information depends on how it is going to be used. And scheduling data can be quite hard to represent well.

If the store hours are simply going to be selected for display, then it doesn't matter how you store them. An array, blob, normalized format or whatever is fine.

More likely, the store hours are going to be used for filtering. This then becomes troublesome.

In the simplest case, there is a direct mapping between days of the week and hours and the service hours never include midnight. In that case, you can have columns, arrays, or a separate table with a start and end time per day.

But then it gets harder if you want to include midnight and have separate hours for holidays. Given the complexity. I would probably suggest having a location-calendar table with rows per location and date. If something is open after midnight, then the table would have two rows in the table (say 00:00 - 02:00 and then 17:00-24:00). You would then prepopulate this table for years into the future. And it can take holidays into account.