How would you build this daily class schedule?

Question

What I want to do is very simple, but I'm trying to find the best or most elegant way to do it. The Rails application that I am creating now will have a daily class schedule. For each class, the fields related to this question are as follows:

• Day of the week
• Start time
• End time

One entry could be something like:

• day of week Wednesday
• start time: 10:00
• end time: noon

I should also mention that this is a bilingual Rails 2.2 application, and I use the built-in i18n Rails feature. I actually have a few questions.

As for the day of the week, should I create an additional table with a list of days, or is there a built-in way to create this list on the fly? Keep in mind that these days of the week should be displayed in English or Spanish as a schedule, depending on the locale variable.

When I request a schedule, I will need to group and order the results on weekdays, from Monday to Sunday, and, of course, order classes for each day, starting time.

Regarding the start and end times of each class, would you use datetime fields or integer fields? If the latter, how would you implement this for sure?

We look forward to new offers that you guys will come up with.

Answer 1

I would just save the day of the week as an integer. 0 => Monday ... 6 => Sunday (or any other way, i.e. 0 => Sunday). Then save the start time and end time as time.

This will simplify the grouping. All you have to do is sort by day of the week and start time.

You can display this in several ways, but here is what I will do.

• They have functions like: @sunday_classes = DailyClass.find_sunday_classes , which returns all classes for Sunday, sorted by start time. Then repeat for each day.

    def find_sunday_classes
     find_by_day_of_week (1,: order -> 'start_time')
   end 

  Note: find_by should probably have an identifier at the end, but that is just the preference in what you want to name the column.

• If you want the whole week, then call all seven from the controller and swipe through them in the form. You can even create detailed pages for each day.

• Translation is the only difficult part. You can create a helper function that takes an integer and returns text for the corresponding day of the week based on the local one.

It is very simple. Nothing complicated.

Answer 2

If your data is time, I would save it as time - otherwise you will always have to convert it from the database when you perform operations related to it with the date and time. This day is redundant as it will be part of the time object.

This means that you do not need to keep a list of days.

If t is time, then

 t.strftime('%A') 

will always give you a day as a string in English. Then it could be transferred to i18n as needed.

Therefore, you only need to save the start time and end time, or the start time and duration. Both must be equivalent. I will be tempted to save the final time myself if you need to manipulate the data by the end time, so it does not need to be calculated.

I think most of the rest of what you are describing should also drop out of time data storage as instances of Time.

Ordering by week and time will simply be ordered by your time column. i.e.

 daily_class.find(:all, :conditions => ['whatever'], :order => :starting_time) 

Grouping by day is a little more complicated. However, this is a great article on how to group by week. Grouping by day will be similar.

If you are dealing with non-trivial data volumes, it might be better to do this in the database using find_by_sql , and this may depend on your time functions and the date of your database, but again storing data as Time will also help you here. For example, in Postgresql (which I use) getting a class week

 date_trunc('week', starting_time) 

which you can use in a Group By clause, or as a value to use in some loop logic in rails.

Answer 3

Repeat the days of the week if you need to have, for example, classes that meet 09: 00-10: 00 on MWF, then you can either use a separate table for several days when the class meets (with a key with both the class identifier and with a DOW), or be evil (that is, unnormalized) and store the equivalent of a DOW array in each class. The classic argument is this:

• A single table can be indexed in such a way as to support either class-oriented or DOW-oriented selection elements, but requires a little more glue to combine the entire image for the class.
• An array of DOWs is easier to visualize for novice programmers and a bit easier to code, but that means DOW considerations require looking at all classes.

If this is only for your personal class schedule, do what gets the value you are looking for from you and live with the consequences; if you are trying to create a real system for multiple users, I would go with a separate table. All of these normalization rules exist for some reason.

As for the (readable) DOW names, this is a presentation level problem and should not be in the basic DOW concept. (Suppose you decide to move to Montreal and need French? It should be a different “face”, not a change in core implementation.)

As for the start / end time, again the problem is in your requirements. If all classes start and end in hours (x: 00), you can use 0..23 as the hours of the day. But then your life would be miserable as soon as you had to adapt this 45-minute workshop. As the old merchant said: "Pay me now or pay me later."

One approach is to define your own ClassTime concept and divide all time considerations into this class. It can start with a simplified view (integral hours 0.23 or integral minutes after midnight 0.1439), and then “grow” as needed.