char or int may not inherently be much to fuss over when the chat gets large
it does become a very big issue. I can't see how a large char could ever
compete against a small int. At the bit level you can not say that
102031
is the same as parsing
122434TREgh-e-rfwer43
so and an so on.
Regardless, comparing int to varchar is measured at the ms level so I
wouldn't worry about it too much...
Steve
<http://intranet>
Stephen E. Schuster
PeopleSoft Administrator
2000 Ashland Drive
Ashland, KY 41101
Office Phone 606.920.7447
Cell Phone 606.831.4590
-----Original Message-----
From: John Quarto-vonTivadar [mailto:[EMAIL PROTECTED]
Sent: Friday, January 02, 2004 3:19 PM
To: CF-Talk
Subject: Re: Create table ID field
This brings up an interesting question I've had for a while: I've seen a few
(but only a few!) developers use CreateUUID() for creating a record's PKID,
and therefore have the PKIDs be strings rather than integers. (their
argument was that they didn't have to worry about another record being
inserted in between when the CreateUUID() was called and when the first
record was actually inserted into the DB) I questioned them about the
impact this has on their joins and a few said they never saw a real decrease
in performance (I don't have any proof, but I inherently distrust that
statement!) and a few others say that they used that only for creating a
unique ID, but that they had a separate ID field in each table that was
numeric which they used for joins. This part seemed like overkill to me -
surely there's some stored procedure that accomplishes all of this?
Can someone who actually thinks about this stuff regularly (uh, that means
you, Dave Watts!) explain whether there's any merit to either group of
people above? I thought the whole point of "autonumber" fields was exactly
to make this issue moot.
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
