Note: Our backend design is based on the Model-View-Controller architecture as implemented in Rails.

Model: Event (events table)

Contains:

• id (int)
• name (string)
• email (string)
• description (text)
• cost (float)
• start_time (datetime)
• end_time (datetime)
• address (string)
• location_square (int)
  • 0 through 15
• food (string)
  • Possible values:(null => "no food", "Free", "$1 hamburgers", etc.)
• sponsor (string)
• popularity (int)
  • still need to come up with algorithm that determines how popular an event is
• archived (boolean)
  • this may be removed
• schedule_id (int)
  • For recurring events. Each event in a series will have the same schedule_id and thus the ability to edit and view at once.
• category_id (int)
  • foreign key for Category model. This should be the lowest level (most specific) category, as opposed to the most general. For instance, Birthday Parties rather than Parties.
• user_id (int)
  • foreign key for User model. This is the creator.

Model: User (users table)

Contains:

• id (string)
• name (string)
• hashed_password (string)
• salt (string)
  • this is used to generate the password hash
• privilege_level (int)
  • -1 = disabled
  • 0 = normal user
  • 1 = RSO or faculty
  • 2 = administrator
• subcribed_to (string)
  • maybe this can be a comma separated list of user_ids or schedule_ids?
• confirmation_code (string)
  • used for registration purposes
• default_location_y (int)
• default_location_y (int)

Model: Category (categories table)

acts_as_tree

Contains:

• id (int)
• name (string)
• parent_id (int)
  • foreign key pointing back to the Category model. This is what allows the categories to act as a tree with subcategories, etc.

Rails allows access to the Category model as a tree. So, the following calls are legal and work as expected:

• @category = Category.find_by_name("Parties").children
• @parent = Category.find(@category.parent_id)

This allows traversal up AND down the category structure.