-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't think it imposes a performance hit and even if it did it's neglible. Once the database has indexed the strings or the ints the lookup cost should be the same. I think it might help if we used fixed char(32) as opposed to varchar(40), but that's mostly a space issue since we are not using the last 8 bytes.
- -Elias Allen Gilliland wrote: > I don't know about why this decision was made historically, but i would > agree that technically this imposes a slight performance hit. AFAIK, > databases can do lookups on purely numeric keys a little bit faster than > alphanumerics. > > I have no idea if the difference is significant or not. > > -- Allen > > > On Tue, 2006-03-14 at 07:25, Lance Lavandowska wrote: > >>IIRC it is largely historical: at one point Roller used Castor, which >>has as it's "default" a GUID generator that creates a 30-char primary >>key. >> >>Lance >> >>On 3/14/06, David M Johnson <[EMAIL PROTECTED]> wrote: >> >>>On Mar 11, 2006, at 4:45 PM, BigLiu wrote: >>> >>>>I want to create some customer tables to extend roller. But I have >>>>question >>>>regarding why the primary key is defined in hex instead of integer? >>>>Will >>>>this cause any performance problem? >>> >>>I can't really remember why I chose the hex key. I don't think it has >>>a significant impact on performance. >>> >>>- Dave >>> >>> > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEFvNdtsNTCOFcV0oRAtpEAJ9iJoF5knx/CyNI6jOnLkmDhGDzLgCgg48v 0QPQh7T9vAl7m3fcmQ2rG00= =3OgD -----END PGP SIGNATURE-----
