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.)
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
