What's the bets route to go for placing a large collection of mp3's into a
DB? Each song will be linked to a particular user Would you put all songs
in one table? make multiple tables based on genre? maybe dynamically
make a songs table for each user as needed?
Dave

Well, users can upload songs they can the listen, rank, tag, and comment
on them and other people's songs even buy them. Think youTube with
music kind of.
Does that help?

>>Why not post a proposed scheme here and let people comment on it?

Well, because my question kind of determines the schema. I'm just wondering
if I should break my songs table into multiple tables or leave it as one.
The only benefit I see to having multiple tables is the size of the
individual tables would be smaller, but I'm not sure that matters though.

Columns in my proposed songs table are:

id, user_id, genre_id, timestamp, name, descrip, icon_file, song_file,
sell_price

/*
Dave -
Adobe Community Expert
www.blurredistinction.com

"Dave Mennenoh" <dave@blurredistinction.comwrote in message
news:fiK2g.2128$1J4.1799@tornado.rdc-kc.rr.com
Well, because my question kind of determines the schema. I'm just
wondering if I should break my songs table into multiple tables or leave
it as one. The only benefit I see to having multiple tables is the size of
the individual tables would be smaller, but I'm not sure that matters
though.

Columns in my proposed songs table are:

id, user_id, genre_id, timestamp, name, descrip, icon_file, song_file,
sell_price
Dave -
There is no major advantage to horizontal partitioning of your songs table.
In the past, partitioning into multiple tables had an advantage as there
were table size limits and through partitioning you could seperate out
tables onto seperate disks. However, in the last decade or so, this has
given way in preferance to hardware RAID configurations.

The only advantage is if either your tables are so large that you perform
table moves on them to defragment them - seperation would keep one set of
data available. Alternatively, if one set of data has attributes that are
districtly different or have specific attributes that always perform part of
the index (e.g. song.active) such that you might consider keeping them in
seperate tables for index performance reasons (however, this is not
recommended).

AM

>>Shouldn't be a problem (apart from the odd named column "timestamp", which
>>should have a name that indicates the content and not the data type). As
>>written somewhere else, you said that the actual songs and other binary
>>data are kept in files outside the database. That ought to work.

Hehe, the 'timestamp' column was more just a note to myself when designing
the schema that I need a timestamp in those records. Thanks for the help
though, I'm relieved knowing this should work ok.

Dave