NYCPHP Meetup

[Gary Mort]

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.

I am no longer convinced that the cpu cycles saved by using a numeric id 
are sufficient to justify doing so with todays computers.  By the time 
you get to an app that is sizable enough to be looking to shave those 
few microseconds, your going to be dealing with a large number of ways 
to save space....and your likely going to want to stick the user mapping 
data into a cache in memory somewhere anyway, so the time saved is not 
that big of a deal.

Also, my main thinking is not from "your custom app written to satisify 
the needs of Woot on a Woot off day"...  I'm thinking more about "your 
open source project designed to be installed on mom and pop systems".

When you have to design to scale, you can go back through and make 
changes for that and afford it.  But trying to design the ideal user 
table structure for a general purpose app and sticking to "good design 
practices" from decades ago is not the best call.

Check the Joomla! or Drupal forums and you will find many people going 
in and doing very hackish things to get the user database to work the 
way they want it.   Not all users of all sites have/want to give you 
their email address[think actual face to face clubs], but both systems 
not only demand one, they demand a unique one.  So the simple solution 
of just assigning all these users the owners email address does not 
work.  I forget which one, I think it was Joomla! , does not recognize 
valid email addresses with a + in them, so you can't even use the common 
trick of <emailname>+<uniqueid>@<domain> .  Well, you can, but you have 
to hack into core code to do it.

Using the outline I specified, you can switch from using "username" as 
the key display to "userid" when and if you need to scale[create an 
update script to map all those names to integers and do it in a batch].

The main thing I'm looking at though is that it is better, in my mind, 
to design a less efficient, more flexible system that everyone can use - 
and place the cost on "tuning" it for scalability on those who can most 
afford it[since if you need to scale and can't afford to pay for it, you 
have a problem], than to make things a little easier for scalability at 
the cost of making more people pay to customize/hack it.