At present the table names and the way the data for course and related content is stored is not very scalable. The reason for this is that earlier when we started building the application there was not enough clarity about the difference between the course and content. There was an understanding that course can be any kind of content (simple text, a document, a video, a text with embedded files). With the latest mockups this relation has become more clear which calls for some code and DB re-factoring to make sure that the design is more scalable and data is as closely modelled with the requirement.

Seeing the current mocks this is how the DB design and the corresponding model design should be:

====== Tables ======

===== courses =====

  * id
  * title
  * raw_data
  * data
  * published_as
  * user_id
  * created_by_id
  * updated_by_id
  * course_type (formal/informal)
  * display_in_catalog
  * display_in_catalog_start_date
  * display_in_catalog_end_date
  * free
  * price
  * created_at
  * updated_at


===== contents =====

  * id
  * title
  * description
  * user_id
  * contentable_type  (can be: Presentation, Video, TextDocument, WebText, Link)
  * contentable_id    (ID of the corresponding table)
  * created_at
  * updated_at

===== course_contents =====

  * id
  * course_id
  * content_id
  * position
  * created_at
  * updated_at

===== assets =====

  * id
  * type
  * attachable_type
  * attachable_id
  * uploaded_data_file_name
  * uploaded_data_content_type
  * uploaded_data_file_size
  * uploaded_data_updated_at
  * processing
  * processing_error
  * user_id

No change in structure except for adding a user_id column

===== web_texts =====

  * id
  * text
  * user_id
  * created_at
  * updated_at

===== links =====

  * id
  * url
  * type  (represents the type of URL i.e video, image, webpage)
  * user_id
  * created_at
  * updated_at


===== Get rid of content_versions table =====

The idea behind the versioning was that a course can simply be some text (with embedded documents). With this thinking it was easier to maintain versions of text (by copying a version to separate table). However now the course is collection of contents of different kind, and this information is stored by associating the course with different contents in an association table (course_contents). We anyway do not store the versions when we implemented the course creation (based on mockups), so no point in keeping the content_versions table. This table just adds more confusion.

====== Impact on current code ======

1. Content model to be renamed to Course. 
  * Update the call to Content class with the new name "Course"
  * update all the associations to point to the updated name
  * If association is renamed then update all the calls to the association with the new name

2. Modify the course_documents table and rename it to course_contents and update it with the structure mentioned above.
  * Update the call to CourseDocument with the new name "CourseContent"
  * update all the associations to point to the updated name

3. Add new table "Contents".
  * Modify the document/asset creation code to create a corresponding row in the contents table when an asset is created.
  * The places where documents are listed i.e. content picker, my learnings content tab has to be changed to refer to contents and not just documents