Context

We are nearing the point where we need an actual database to store off-campus restaurant data, grubhub locations, and reviews. To keep things cleaner, it’ll be wise to move our current in-memory data into this database as well.

Database layout

The main point of discussion will likely be the open hours table, where instead of having a list of (start, end) time intervals, the columns defined have an additional constraint that they are tied to a specific date. (and thus each interval can be at most 24 hours long). I claim this has the following benefits

• Easier to update the database with scraped data, which is often in the form Mon: <time>, Tue: <time>, etc.
  • If we’re just storing time intervals, how do we know precisely which ones to overwrite when we rescrape?
• Per-date time overwrites are simpler as well

This will likely introduce a breaking change for the API as well.

Mapping from concept id to internal id table (will be useful if dining screws up their concept ids or if we add grubhub or location data from other external sources)

• external id (ex. conceptid)
• Internal id

[insert new entry if external id not found]

Location Table

• Internal id, primary key
• Name
• Location
• Coordinates
• Link
• Specials (extra table)