OstDB DEV: Difference between revisions

Jump to navigation Jump to search
1,010 bytes added ,  27 February 2007
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?
* maybe linking the MetaData and FileSys.Data to the submitting user?
** (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?:

Navigation menu

MediaWiki spam blocked by CleanTalk.
MediaWiki spam blocked by CleanTalk.