Designed DB for performance

[Angeleyezz]

I am putting together a table that has user information.  basic info, name, address, tele, account status, etc.  My question is should I keep all of that in a seperate table and just relation to it through an account ID, and only pull the data when I need it from the other table?  or will that end up making more processes for the server every time it needs the info it has to pull data from 2 tables instead of 1 table with lots of fields?

[benanamen]

Your answer lies in understanding "Database Normalization". Look it up and learn it well. It will always be important to know when designing databases.

[Stielle]

Yes, database normalization is what you want to check into. It is where you set up your database by organizing it to reduce data repetition. It is primarily designed to improve the data integrity, but can be used to optimize its efficiency too.

[Angeleyezz]

Ahh normalization, I knew there was a term for it, just couldnt remember what it was.  Thanks guys!!!! been a long time since i've worked with any of this, but I'm just getting back into it.

[Jacques1]

Your original post sounds like you want to artificially split your original table into many small tables, so that the database system doesn't have to "deal with all data at once". Don't do that. Modern database systems are a lot smarter than you seem to think and only load the data which is actually used. Besides that, even gigantic tables with hundreds of columns and millions of rows are no problem at all -- I'm sure you have less than that. So there is absolutely no need to "keep tables small". In fact, this is counter-productive and will likely lead to a total mess.

 

What you should take care of is correctness, not your naive understanding of "performance".