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?
|
Список | 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 по дате отправления: