I am trying to design a Database for a music-taste-sharing web application.
I pretty much never have to do Db design/architecture and thought I’d get some help from SO users and hopefully my question could become a nice example of “good” Db design practices.
FYI: The ERD was drawn using MySQL Workbench which is a FREE software.
These are my requirements and how I represented them in the Db schema
-
user has credentials & an account/profile (email, fName, lName, & so on) – all this is under the
USER_DETAILStable -
user can have role(s) & & several users can have the same role(s) – hence the many-to-many relationship between
USER_DETAILS&ROLEtables -
user can have images – hence the one-to-many relationship between
USER_DETAILS&USER_IMAGEtables -
user can have many badges & several users can have the same badge(s) – hence the many-to-many relationship between
USER_DETAILS&BADGEtables -
user’s track can have many reputation history & a reputation history is only matching one specific user’s track – hence the one-to-many relationship between
USER_DETAILS_TRACK&REPUTATION_HISTORYtables -
user can have many tracks & several users can have the same track(s) – hence the many-to-many relationship between
USER_DETAILS&TRACKtables -
user can have tag(s) per track & several users can have the same tag(s) per track – hence the many-to-many relationship between
USER_DETAILS_TRACK&TAG_2tables -
track is represented under has
TRACKtable -
track can have several artists & an artist can be in several tracks – hence the many-to-many relationship between
TRACK&ARTISTtables -
track can have several releases & an releases can (& usually) have several tracks – hence the many-to-many relationship between
TRACK&RELEASEtables -
release has one release_type & a release_type can be in many releases – hence the one-to-many relationship between
RELEASE_TYPE&RELEASEtables (a release type would be an album, an EP, an LP, a single & so on) -
track can have comments – hence the one-to-many relationship between
TRACK&COMMENTtables -
track can have several tags & an artist can be in several tracks – hence the many-to-many relationship between
TRACK&TAG_1tables
You must have noticed that I have duplicated the TAG table has TAG_1 & TAG_2. Ideally I would only have one but I am afraid that would create a coupling far too strong between USER_DETAILS_TRACK & TRACK tables as these are already linked with a many-to-one relationship.
I plan to keep TAG_1 & TAG_2 synchronized in the middle tier.

Latest edit after podiluska’s comments

- Am I on the right path regarding my db design?
- What would you modify/improve?
Thanks a LOT
Apart from the adjustments made in the comments, I think it’s now more or less there.
You need to either remove Track_ID from Release and replace it with Release_ID in track, or have a TrackRelease table – depending on whether a track can be on more than one release, and vice versa.