340
edits
OstDB DEV: Difference between revisions
→Approach 1
| Line 43: | Line 43: | ||
To Fix: | To Fix: | ||
* if a ArtistOrBand entry is a Band it needs a name | * if a ArtistOrBand entry is a Band it needs a name (EXP: true) | ||
* maybe linking the MetaData and FileSys.Data to the submitting user? | |||
** (EXP) might come in handy in some cases, but on the other hand it'll increase the data size. but it's probably a good idea. It would make it easier to ensure that we're not counting the submittions of a user multiple times. and we could also display the user's personal metatags/filenames on his pages. | |||
Needs Feedback: | |||
* more than one MetaData field for a AudioFile? | * more than one MetaData field for a AudioFile? | ||
* | ** (EXP) the diagram says that already, doesn't it? (NOTE: multiplicities are used according to UML class diagram conventions, not ER diagram conventions) | ||
* maybe add a CollectionFile table for zip, rar, ... packed releases linked to AudioFile, Collection and Group? | * maybe add a CollectionFile table for zip, rar, ... packed releases linked to AudioFile, Collection and Group? | ||
** (EXP) do we really need to support packed releases? most users would extract archives anyway. But even if we want to support them, we won't need another table for that. The song<->file relation is M:N, meaning that one file can already contain multiple songs. I wouldn't add archives though. If we really have to, the client software could extract archives on the fly and hash the audio which are inside. The one-file:multiple-songs case was rather meant for those lossless audio files which may contain an entire cd. | |||
Don't Fix?: | Don't Fix?: | ||