From: | "D(dot) Dante Lorenso" <dante(at)lorenso(dot)com> |
---|---|
To: | David Garamond <lists(at)zara(dot)6(dot)isreserved(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Drawbacks of using BYTEA for PK? |
Date: | 2004-01-12 18:01:06 |
Message-ID: | 4002E0E2.7030208@lorenso.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> Tom Lane wrote:
>
>> Adding an MD5 hash contributes *absolutely zero*, except waste of space,
>> to any attempt to make a GUID. The hash will add no uniqueness that was
>> not there before.
>
The cool thing about a 'GUID' (or in my example a hashed sequence number
[sure
toss in some entropy if you want it]) is that if you happen to reference
that
value as a primary key on a table, the URL that passes the argument can not
be guessed at easily. For example using a sequence:
http://domain.com/application/load_record.html?customer_id=12345
Then, users of the web will assume that you have at most 12345
customers. And
they can try to look up information on other customers by doing:
http://domain.com/application/load_record.html?customer_id=12346
http://domain.com/application/load_record.html?customer_id=12344
...basically walking the sequence. Sure, you will protect against this with
access rights, BUT...seeing the sequence is a risk and not something you
want
to happen. NOW, if you use a GUID:
http://domain.com/application/load_record.html?customer_id=f46d6296-5362-2526-42e3-1b8ce9dcccc1
Right, so now try to guess the next value in this sequence. It's a little
more protective and obfuscated (an advantage in using GUIDs).
Dante
From | Date | Subject | |
---|---|---|---|
Next Message | elein | 2004-01-12 18:01:49 | Re: History-based (or logged) database. |
Previous Message | scott.marlowe | 2004-01-12 17:58:22 | Re: Case sensitivity |