NYCPHP Meetup

[Paul A Houle]

  On 3/5/2011 1:27 PM, Gary Mort wrote:
> 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.
>
     It's not cpu cycles that matter here,  but I/O bandwidth,  seek 
time,  and RAM for cache on your  database server.  Although MySQL in an 
impressive product,  it's remarkably easy to put enough data into a 
database that you'll have performance problems,  particularly if you're 
importing data from public sources or if you develop a successful 
community site.

     32-bit integer identifiers are easy to use for both small systems 
and systems that need to handle up to a billion or so data items.  
Although you can possibly convert some other kind of identifier into an 
int in the future,  this is the last thing you're going to want to do 
when your system gets big,  because changing all of your identifiers 
will then require extended downtime and leaves you with the risk of 
dropping something on the floor.

     For one system I'm working on,  identifiers are fully 
encapsulated,  so at some point I can upgrade my identifiers to 
BINARY(5) if I ever run out of 32-bit id's.  (I'm about 5% of the way 
there now.)