galvin Posted August 23, 2011 Share Posted August 23, 2011 I am just trying to understand "normalization" better so if it's impossible to answer with just a sentence or two, then I would welcome any links to more in-depth explanations of normalizing tables. Say we have these tables for a football picks pool (columns in parentheses)... Users (email, name, userid) Teams (teamcity, teamnickname, teamid) Picks (userid, pickid, week, teamid) Into the picks table, we'd enter a pick each week (i.e. for week1, week2, etc). I wonder why it's not easier to just have the users and picks table combined into one table (i.e. have columns for each user for "week1pick, week2pick, week3pick, etc). Might be more work up front (setting up the table), but seems like it'd be easier to query info from just ONE table rather than having to do joins and whatnot from multiple tables. Is there an easily explained reason why doing it that way is bad/stupid ? Any info would be appreciated Just trying to understand the WHY as best I can. Quote Link to comment Share on other sites More sharing options...
fenway Posted August 23, 2011 Share Posted August 23, 2011 Well, at some level, "users" and "picks" are completely different entities, so it's logical to keep them separate. What if you later change you design to allow for multiple picks per week? With 2 tables, that's easy -- with a combined table, that's all but impossible. If you store your entities cleanly, your application can mature without difficulty. If, instead, you choose to store the current relationships you require, you'll never be able to change them. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.