Re: Drawbacks of using BYTEA for PK?
От | Chris Travers |
---|---|
Тема | Re: Drawbacks of using BYTEA for PK? |
Дата | |
Msg-id | 01d501c3d9d5$04686dc0$54285e3d@winxp обсуждение исходный текст |
Ответ на | Drawbacks of using BYTEA for PK? (David Garamond <lists@zara.6.isreserved.com>) |
Список | pgsql-general |
From: "John Sidney-Woollett" <johnsw@wardbrook.com> >Careful... > If two (or more) clients (in the same network) are going through a > firewall that performs NAT, then they could appear to have the same IP > address if the NAT address pool is small (single address). Sorry, I should have been more specific about what I meant by "Unique address." The unique address is some identifier which can be reasonably considered to be unique to the system md5(serial number of the first CPU || make/model of the CPU) or md5(mac address || ipv4 address) or ipv6 address. Concatinating this with a timestamp and a sequence should provide very little chance of a collision. Here is a more interesting application though-- suppose you have a distributed environment and want a way of transparently authenticating where a record is supposed to be. In this scenario, you have a situation where you need some sort of GUID for the database server, which can be specified when an addition is made or where the referring record exists. If the record exists in a different location the other child records could be deflected there too (perhaps via dblink). In this way, the pseudo-guid can contain the customer number along with the location guid. Any suggestions on handling this in a manageable and opaque fashion (i.e. not giving customers case numbers with the mac address fo the server appended ;-)) Best Wishes, Chris Travers
В списке pgsql-general по дате отправления: