Re: Drawbacks of using BYTEA for PK?

Поиск
Список
Период
Сортировка
От D. Dante Lorenso
Тема Re: Drawbacks of using BYTEA for PK?
Дата
Msg-id 4002E0E2.7030208@lorenso.com
обсуждение исходный текст
Ответ на Re: Drawbacks of using BYTEA for PK?  (David Garamond <lists@zara.6.isreserved.com>)
Ответы Re: Drawbacks of using BYTEA for PK?  ("scott.marlowe" <scott.marlowe@ihs.com>)
Список 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








В списке pgsql-general по дате отправления:

Предыдущее
От: Jeff Eckermann
Дата:
Сообщение: Re: what we need to use postgresql in the enterprise
Следующее
От: elein
Дата:
Сообщение: Re: History-based (or logged) database.