Layout - Database design

[jonahdlin]

Database Skeleton

New tables in database to store layout information. Adapt this basic DB skeleton to adapt to RethinkDB.

• Table to associate URIs with unique ID numbers for layouts (to minimize how much needs to change when a URI changes)
  • Columns
    • ID
    • URI
    • Date added (URI)
• Table to associate IDs with layouts
  • Columns
    • ID
    • URI ID (how layouts are referenced, retrieved from first table)
    • Layout (stored as CSV? or JSON?)
    • Date submitted
    • User ID (refers to either a logged in admin, or a regular, and anonymous user)
• Table to store user IDs and information about permissions/privileges
  • This is the lowest priority task, because it's not essential to actually finishing the project
  • Columns
    • ID
    • Username
      • If "default" username, which can be something like "everyone", user is given lowest influence over final layout decision
    • Passwords
      • We don't know what hash function to use for these
    • User type
      • Could potentially be stored here as an ID that is stored in another table with useful information about user types
• Cache table to store history of computed layouts (including most recent)
  • This table can be erased at any time, and the most recent layout amalgamation will be recalculated and stored
  • Columns
    • ID
    • URI ID
    • Date submitted
      • This field is used to compare with the submitted layout table. If the latest date submitted here is less than the latest date submitted there, the newest table must be recalculated
    • Date deleted
      • This field is null unless a layout is purposefully marked to be ignored, but isn't deleted from the database. Every call to the database should ignore rows where this field is not null