NYCPHP Meetup

[David Krings]

On 3/4/2011 3:07 PM, D. J. Waletzky wrote:
> The problem with eliminating "redundant" info in a user table is that it
> may not scale terribly well. I always take care to give any user table
> an auto_incremented row number/uid, because the user's handle and
> e-mail, though unique, may change. Without an independent index
> changing either of these columns in the user table will cause all kinds
> of headaches in other linked tables. With a row number you can save
> space and CPU cycles by using numeric IDs for foreign keys.

 From my experience it isn't worth the effort to remove "redundant" info, what 
I assume is meant as normalizing tables. I don't think the numeric key is the 
culprit in scaling issues, but the many joins one has to make across tables. 
Also, when something goes wrong and you need to dig through the tables it is a 
pain in the you know where to hangle from one table to the other to gather up 
all the information that you need.
Stick everything into one table and if it makes sense duplicate partial data 
in a different table to minimize joins. Not only are the queries much simpler 
then and get executed faster, figuring out what goes on is also much easier. 
As a side effect you can find data inaccuracies easier and fix them as well. 
The downside is drive space usage, which will go up. But the times where a 
120MB hard drive cost 800$ are long gone - and so is the prime reason for 
normalization.


David