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

Предыдущее
От: "John Sidney-Woollett"
Дата:
Сообщение: Nested transaction workaround?
Следующее
От: Anton.Nikiforov@loteco.ru
Дата:
Сообщение: Re: insertion with trigger failed unexpectedly