I think you're approaching this from the wrong angle. You'll want to put
the data at the highest level at which it changes.
i.e. If every song on an album is always the same year, put it at the
album level, however, if it changes from song to song on a particular
album, then you want it at the song level.
Year wouldn't ever apply to artist I don't think, unless they're truly a
one hit wonder. :)
-Micah
On 04/02/2007 09:14 PM, Daniel Cousineau wrote:
So I'm currently designing a database for a web site and intra net for my
campuses student radio. Since I'm not getting paid for this and I'm doing
this in my free time I kinda want to take my time and have the system
setup
as "perfectly" as any one college student can.
I'm currently debating on how I want to store all the songs in the
system.
Namely I'm not quite sure which way will eek the most performance out of
MySQL.
My plan so far is quite normalized, a songs table with 1:1 relationships
with an Albums, Artists, and Genres table.
The big benefits I see from this is when I'm building the intra net
application I'll want to pull just all of the artists or all of the
albums,
etc. However I feel like I'm encountering issues with where to store the
"year" field of an mp3 (do I want it on the album, song, or both)
along with
issues like printing everything out at once.
The only other way I can think of thats relatively efficient is to
have the
singular songs table and have indexes on albums, artists, and genres.
My question, more out of curiosity than necessity, is which of these
would
be more efficient (given that I'll be using the InnoDB storage engine)?
Other relevant facts include it'll be using the latest, stable release of
MySQL 5 and I'll be developing in PHP5 (through CakePHP's database
abstraction layer).
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
