Am 12.08.2008 um 17:21 schrieb Bill Moran:
In response to Moritz Onken <onken@xxxxxxxxxxxxxxxx>:
Am 12.08.2008 um 17:04 schrieb Bill Moran:
In response to Moritz Onken <onken@xxxxxxxxxxxxxxxx>:
We chose UUID as PK because there is still some information in an
integer key.
You can see if a user has registered before someone else
(user1.id <
user2.id)
or you can see how many new users registered in a specific period
of
time
(compare the id of the newest user to the id a week ago). This is
information
which is in some cases critical.
So you're accidentally storing critical information in magic values
instead of storing it explicitly?
Good luck with that.
How do I store critical information? I was just saying that it easy
to get some information out of a primary key which is an incrementing
integer. And it makes sense, in some rare cases, to have a PK which
is some kind of random like UUIDs where you cannot guess the next
value.
I just repeated your words. Read above "this is information which
is in
some cases critical."
If I misunderstood, then I misunderstood.
If you are using incrementing integers as pk then you are storing this
data implicitly with your primary key. Using UUIDs is a way to avoid
that.
