Design database

[syoon123]

Browse audiopedia.app and audiopedia.io, as well as the old codebase. Sketch a diagram of the models/relationships you think we'll need (refer to this tutorial for information on database structure and design notation, but no need to use the tool — hand-drawn is fine).

[syoon123]

@tp0119 — These were our notes for your database design:

• Language not accounted for; perhaps create Language model with id, name, and audio_url that would have a many-to-one relationship with each of the other models? Or, if there is another way to have store translations in a relational database that is better performance-wise or just more common practice, provide that justification and update the DB design accordingly
• Add audio_url to Topic and Playlist model (everything — language names, playlist/topic titles — is read aloud)
• Remove duration from Playlist model — we would need to update that every time tracks are added or removed (keeping this accurate is messy and unnecessary)
• Separate timestamp and duration on Track model — all models should instead have created_at and updated_at timestamps (they will probably inherit these from an abstract base class we'd define called TimestampedModel), and the duration of a given Track would be a separate attribute
• The order in which topics/playlists/tracks are played needs to be mutable; rather than trying to change id on models we should probably have some kind of index stored separately?
• If we give the admin the ability to "archive" topics/playlists/tracks we should have some kind of flag (maybe called active) on the base model that would get set to False upon removal/archiving

[tp0119]

@tp0119 — These were our notes for your database design:

• Language not accounted for; perhaps create Language model with id, name, and audio_url that would have a many-to-one relationship with each of the other models? Or, if there is another way to have store translations in a relational database that is better performance-wise or just more common practice, provide that justification and update the DB design accordingly
• Add audio_url to Topic and Playlist model (everything — language names, playlist/topic titles — is read aloud)
• Remove duration from Playlist model — we would need to update that every time tracks are added or removed (keeping this accurate is messy and unnecessary)
• Separate timestamp and duration on Track model — all models should instead have created_at and updated_at timestamps (they will probably inherit these from an abstract base class we'd define called TimestampedModel), and the duration of a given Track would be a separate attribute
• The order in which topics/playlists/tracks are played needs to be mutable; rather than trying to change id on models we should probably have some kind of index stored separately?
• If we give the admin the ability to "archive" topics/playlists/tracks we should have some kind of flag (maybe called active) on the base model that would get set to False upon removal/archiving

Notes have been addressed! Updated database design is in the master branch.