4
edits
OstDB DEV: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
mNo edit summary |
|||
| Line 43: | Line 43: | ||
To Fix: | To Fix: | ||
* if a ArtistOrBand entry is a Band it needs a name (EXP: true) | * if a ArtistOrBand entry is a Band it needs a name [[User:Ace|Ace]] (EXP: true) | ||
* maybe linking the MetaData and FileSys.Data to the submitting user? | * maybe linking the MetaData and FileSys.Data to the submitting user? [[User:Ace|Ace]] | ||
** (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. | ** (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: | Needs Feedback: | ||
* maybe add a CollectionFile table for zip, rar, ... packed releases linked to AudioFile, Collection and Group? [[User:Ace|Ace]] | |||
* 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. | ** (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?: | ||
* we can't store very complex cases, but maybe we don't need to | * we can't store very complex cases, but maybe we don't need to | ||
* more than one MetaData field for a AudioFile? [[User:Ace|Ace]] | |||
** (EXP) the diagram says that already, doesn't it? (NOTE: multiplicities are used according to UML class diagram conventions, not ER diagram conventions) | |||
*** right sorry [[User:Ace|Ace]] 11:13, 27 February 2007 (UTC) | |||
Fixed?: | Fixed?: | ||