Question

i am working on a project in which people can create a playlist and its stored in localStorage as objects. everything is client side for the moment.

so i will now like to take a leap forward, make a user login system (i can do it using php mysql and fb connect or oauth system, any other suggestions?). the problem is deciding if i make a sql database for each user and store their playlist (with media info) or is there any other way to go around. will handling a large number of databases be a trouble for me(in terms of speed)?

how about i create only one db as follows:

user database —> one table containing{ user(primary key) pass someotherInfo} , then tables per USER {contains playlists) , 3rd table per playlist (containing userID and media info, what could be my primary key?)

example:
i have 10 registered user, each user has 2 playlists

1.table 1: 10 entries
2.table(s): username - playlists (10 tables) || i make one table with one field user other field playlist name
3.tables: each playlist - media info, owner (20 tables)

or is there a simpler way?

i hope my question is clear.

PS: i am new to php and database (so this might be very silly)

Answer 1

Surprised most answers seems to have missed the question, but I’ll give this a try;

This is called data modeling (how you hobble a bunch of tables in a database together in order to express what you want in the best possible way), and don’t feel silly for asking; there are people out there who spend all their waking hours tweaking and designing data models. They are hugely important to the well-being of any system, and they are, in truth, far more important that most people give them credit for.

It sounds like you’re on the right path. It’s always a good tip to define your entities, and create a table per each, so in this case you’ve got users and playlists and songs (for example). Define your tables thusly; USER, SONG, PLAYLIST.

The next thing is defining the names of fields and tables (and perhaps the simplistic names suggested above are, well, simplistic). Some introduce faux namespaces (ie. MYAPP_USER instead of just USER), especially if they know the data model will extend and expand in the same database in the future (or, some because they know this is inevitable), while others will just ram through whatever they need.

The big question will always be about normalization and various problems around that, balancing performance against applicability, and there’s tons and tons of books written on this subject, so no way for me to give you any meaningful answer, but the gist of it for me is;

At what point will a data field in a table be worthy of its own table? An example is that you could well create your application with only one table, or two, or 6 depending on how you wish to split your data. This is where I think your question really comes in.

I’d say you’re pretty much correct in your assumptions, the thing to keep in mind is consistent naming conventions (and there’s tons of opinions of how to name identifiers). For your application (with the tables mentioned above), I’d do ;

USER { id, username, password, name, coffee_preference } 
SONG { id, artist, album, title, genre } 
PLAYLIST { id, userid } 
PLAYLIST_ITEM { id, songid, playlistid, songorder }

Now you can use SQL you get all playlists for a user ;

   SELECT * FROM PLAYLIST WHERE userid=$userid

Or get all songs in a playlist ;

   SELECT * FROM SONG,PLAYLIST_ITEM WHERE playlist_item.playlistid=$playlist.id AND song.id=playlist_item.songid ORDER BY playlist_item.songorder

And so on. Again, tomes have been written about this subject. It’s all about thinking clearly and semantically while jotting down a technical solution to it. And some people have only this as a career (like DBA’s). There will be lots of opinions, especially on what I’ve written here. Good luck.