design for speed?
Posted: Thu Aug 11, 2005 1:28 am
Let's say you have a database table for user information that has about 20 fields that describe information about the user. Now, it is easy to keep all this information in 1 table and quite easy to query it. However, is it beneficial to split this up into 2 tables. The first containing the bare minimums about the user such as the username and password. The second containing all the information about the user.
Does this speed up queries by a noticeable amount.
Also, let's say your user base starts getting quite large (>500000 users). Is it wise to start splitting up your databases and/or tables? For example, store users with last names A-J in one database (or table) and users with last names K-Z in another database (or table). Does something like that help enough to have to go through the hassle of implementing the procedure?
I guess I'm looking for some general design methodologies.
Thanks very much for all your help.
Jonathan
Does this speed up queries by a noticeable amount.
Also, let's say your user base starts getting quite large (>500000 users). Is it wise to start splitting up your databases and/or tables? For example, store users with last names A-J in one database (or table) and users with last names K-Z in another database (or table). Does something like that help enough to have to go through the hassle of implementing the procedure?
I guess I'm looking for some general design methodologies.
Thanks very much for all your help.
Jonathan