-
From: Dave Watts [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 23, 2008 11:48 PM
To: CF-Talk
Subject: RE: Any Gotcha's in using CF UUID for db record primary key?
At the same time I kind of DON'T agree with them if you're
doing what we were doing: if you're using the key to link
tables (so
value...you
KNOW what it is...everytime, because you set it, not the DB.
Mark
-Original Message-
From: Rick Faircloth [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2008 8:22 AM
To: CF-Talk
Subject: RE: Any Gotcha's in using CF UUID for db record primary key?
What's the reason
in Coldfusion or someother unique value...you
KNOW what it is...everytime, because you set it, not the DB.
Mark
-Original Message-
From: Rick Faircloth [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2008 8:22 AM
To: CF-Talk
Subject: RE: Any Gotcha's in using CF UUID for db record primary key
I'm thinking about changing from using auto-incrementing integers
to CF-generated UUID's for primary keys in my mysql db's.
Keep in mind that primary keys are by definition indexed, and in order
to maintain an index,
keys are compared to others. Now comparing to numbers takes only one
machine
: Rick Faircloth [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2008 8:22 AM
To: CF-Talk
Subject: RE: Any Gotcha's in using CF UUID for db record primary key?
What's the reason for using the db instead of CF to
generate the UUID? To keep the load off CF?
I was thinking I might use CF
understanding? No locks, no transactions needed?
Rick
-Original Message-
From: Greg Morphis [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2008 10:18 AM
To: CF-Talk
Subject: Re: Any Gotcha's in using CF UUID for db record primary key?
But can't you put a cflock / around
But can't you put a cflock / around the query that inserts
the record and retrieves the last ID?
If you want to serialize database transactions, that's what the
CFTRANSACTION tag is for.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
Fig Leaf Training: Adobe/Google/Paperthin
And this is the info in the MySQL 5 docs that convinced me
that LAST_INSERT_ID() was a safe means of retrieving id's,
even with unlimited number of users working simultaneously...
==
The ID that was generated is maintained in
What if you have four concurrent users (or four hundred if
your app get popular!), what happens if user two gets user
three's id when she runs LAST_INSERT_ID()?
This is exactly why databases provide concurrency control. You should use
it.
That's the one of the only reasons I can see for
What's the reason for using the db instead of CF to generate
the UUID? To keep the load off CF?
Primarily, because that sort of thing is the database server's job, in the
same way that calculating aggregates is something better left to the
database server than your application.
There are
www.cfwebtools.com
www.coldfusionmuse.com
www.necfug.com
-Original Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2008 10:23 AM
To: CF-Talk
Subject: RE: Any Gotcha's in using CF UUID for db record primary key?
What's the reason for using the db instead of CF
Dave, what issues do you speak of? I know that UUID creation is NOT
fast, but when you say issues, it leads me to think you mean
multiple bugs.
On Mon, Mar 24, 2008 at 10:23 AM, Dave Watts [EMAIL PROTECTED] wrote:
What's the reason for using the db instead of CF to generate
the UUID? To
sequential GUIDs. [ newSequentialID() ] Please
enlighten me as I must be considering too simple of a scenario.
~Brad
-Original Message-
From: Raymond Camden [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2008 10:39 AM
To: CF-Talk
Subject: Re: Any Gotcha's in using CF UUID for db record
Dave, what issues do you speak of? I know that UUID creation
is NOT fast, but when you say issues, it leads me to think
you mean multiple bugs.
http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:51685#278231
http://www.bpurcell.org/blog/index.cfm?mode=entryentry=970
Dave Watts,
Wow, that convinces me. ;)
On Mon, Mar 24, 2008 at 11:22 AM, Dave Watts [EMAIL PROTECTED] wrote:
Dave, what issues do you speak of? I know that UUID creation
is NOT fast, but when you say issues, it leads me to think
you mean multiple bugs.
Rick Faircloth wrote:
I'm thinking about changing from using auto-incrementing integers
to CF-generated UUID's for primary keys in my mysql db's.
Any drawbacks in doing that?
1. Storage size.
Let's suppose you have a table for a many-to-many relation. That is 72
bytes for the 2 fields and
Rick Faircloth wrote:
The ID that was generated is maintained in the server on a per-connection
basis.
This means that the value returned by the function to a given client is the
first AUTO_INCREMENT value generated for most recent statement affecting an
AUTO_INCREMENT column by that client.
Rick Faircloth wrote:
I'm thinking about changing from using auto-incrementing integers
to CF-generated UUID's for primary keys in my mysql db's.
Any drawbacks in doing that?
1. Storage size.
==
I'll ditto that. Our Database is a healthy 32 Gigs or so. We used
I need to become more familiar with using unique constraints, etc
Yes you do! Do it now and save yourself pain later ;) Relying on a primary
key to make a table row unique invariably leads to duplicate data (even
though they have unique keys) which is a royal PITA. As a general rule,
every
What if you have four concurrent users (or four hundred if
your app get popular!), what happens if user two gets user
three's id when she runs LAST_INSERT_ID()?
This is exactly why databases provide concurrency control. You should use
it.
That's the one of the only reasons I can see for
Hi Rick,
Personally, I would still use an auto-incrementing integer for the PK but
have the UUID as a separate field with a unique constraint. Primary keys are
not for making a single row unique but for facilitating the relational bit
of relational databases (i.e. defining Foreign Key
as
the relational key instead of the PK.
I need to become more familiar with using unique constraints, etc.
Rick
-Original Message-
From: Dominic Watson [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 23, 2008 7:10 PM
To: CF-Talk
Subject: Re: Any Gotcha's in using CF UUID for db record primary
The main reason I'm thinking about swapping is so I can eliminate
the two-step process of creating, say, a database record for a
new Real Estate development community for the textual information,
and then requiring a user to click a link with the record id in the URL
to add photos for
Keep you pk like it is...auto incrementing...and add another field with uuid
and then you can reference them
-Original Message-
From: Rick Faircloth [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 23, 2008 7:38 PM
To: CF-Talk
Subject: RE: Any Gotcha's in using CF UUID for db record primary
Gotcha's in using CF UUID for db record primary key?
Thanks for the feedback, Dominic.
I'll have to do some more research on this approach.
I was thinking that the UUID would take the place of using
the PK my databases, as in:
a href=community.cfm?community_uuid=#url.community_uuid
and I would
For what it's worth I kind of agree with the others about the performance
benefits... but at the same time the busiest site I've ever worked on (and
my personal site, since it's built using the same engine) uses only UUIDs
for PKs and never had an issue because of it.
We used them, as I assume
,
you've got the GUID in not only one table, but MULTIPLE tables. Stick with
the integer field for PK.
-Original Message-
From: Dominic Watson [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 23, 2008 6:10 PM
To: CF-Talk
Subject: Re: Any Gotcha's in using CF UUID for db record primary key
Sounds like there are definite pros and cons to UUID usage.
And, too, this seems to be a case of need driving functionality.
With high traffic sites, I can see the need for various indexes, etc.
My db's will all be relatively small and won't have issues
with high traffic. I've never even had to
At the same time I kind of DON'T agree with them if you're
doing what we were doing: if you're using the key to link
tables (so that you can combine multiple databases easily)
and using them to link to non-DB information (log files, etc)
then it seems like extra work to do a real
29 matches
Mail list logo
