I have a webapp I'm making that stores user information, and their preferences regarding the app. Is this something worth splitting into two databases? I was thinking one table "users" with fields "id, useridfromFacebook, facebookRealName" (so 1, 52052025295, Alex McP), and then have a table "preferences" with fields "id, useridfromFacebook, emails, colors, SomeQuoteorSomething" (4, 52052025295, 1, 441155, 'Only The Good Die Young')
I've never been taught/learned myself about DB setup, but this seems like it would limit the load on the database because when a user is authenticated and has installed the app, I would only need to query the preferences table if(isset($fbauthboolean)) or something.
Thoughts? Can I clarify this?
Thanks!
I confused the words "database" and "table" in my original posting. Edited. I'd have just ONE DB with multiple tables, but all relating to the same user. One table contains NAME data, and the other table would store PREFERENCES type data
I wouldn't think you'd need two databases, but you might want separate tables in the same schema.
I really liked Toby Teorey's "Database Modeling and Design". See if you agree.
I also like the Database Programmer blog. Very helpful, good writing.
If you don't want to buy a book, you might want to Google for normalization.
For your preferences table, I'd go something like
Where preference was some code like 'Quote','AboutMe', etc, and value being a string.
You could even have a preference_value table with a list of 'QUOTE','Funny Quote'/'ABOUTME, 'About Me', etc