340
edits
No edit summary |
|||
Line 17: | Line 17: | ||
===Approach 1=== | ===Approach 1=== | ||
Here is one possible way of realizing the database structure, not exactly 100% correct UML but you should get the idea. Classes are supposed to represent database entities. Lots of attributes are still missing. But I'd like some feedback on whether this general structure would be viable. | Here is one possible way of realizing the database structure, not exactly 100% correct UML but you should get the idea. Classes are supposed to represent database entities. Lots of attributes are still missing. But I'd like some feedback on whether this general structure would be viable. | ||
[[Image:OstDbDraft1.png]] | |||
=Vision= | =Vision= | ||
The general idea would be that AniDB clients would be extended with audio file support and would automatically provide anidb with lots of raw data on audio files being collected by it's userbase. For so far unknown audio files interested users (aka work monkeys) would either use a client or the webinterface to specify the song (or add it, if it is not yet listed on anidb). | The general idea would be that AniDB clients would be extended with audio file support and would automatically provide anidb with lots of raw data on audio files being collected by it's userbase. For so far unknown audio files interested users (aka work monkeys) would either use a client or the webinterface to specify the song (or add it, if it is not yet listed on anidb). | ||
Known audio files could automatically be added to the users my(ost)list, could be renamed or their ID3/Comment data could be updated. | Known audio files could automatically be added to the users my(ost)list, could be renamed or their ID3/Comment data could be updated. |