pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedsurrogate keys and replication.
2+ messages / 2 participants
[nested] [flat]
* surrogate keys and replication.
@ 2004-07-27 06:36 sad <sad@bankir.ru>
2004-08-09 17:33 ` Re: surrogate keys and replication. Josh Berkus <josh@agliodbs.com>
0 siblings, 1 reply; 2+ messages in thread
From: sad @ 2004-07-27 06:36 UTC (permalink / raw)
To: pgsql-sql
Josh,
I agree to treat this case as a (1) convinence.
But it is still very cpecific, more than just simplifying FKs
And you have said about general GUID problem.
Let we disscuss this problem ? I hope to here good ideas from you again.
Now I solve the GUID problem, with one sequence of IDs on the main server.
The clients ask the server to lease some IDs via special (application-layer)
protocol. Server remembers who and when and what IDs have took.
(in terms of segments [a..b],[c..d]... etc)
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: surrogate keys and replication.
2004-07-27 06:36 surrogate keys and replication. sad <sad@bankir.ru>
@ 2004-08-09 17:33 ` Josh Berkus <josh@agliodbs.com>
0 siblings, 0 replies; 2+ messages in thread
From: Josh Berkus @ 2004-08-09 17:33 UTC (permalink / raw)
To: sad <sad@bankir.ru>; pgsql-sql
Sad,
> Now I solve the GUID problem, with one sequence of IDs on the main server.
> The clients ask the server to lease some IDs via special
> (application-layer) protocol. Server remembers who and when and what IDs
> have took.
> (in terms of segments [a..b],[c..d]... etc)
Sorry for long delay on this -- I've been out of town.
I don't know what the limitations of your client-side technology are.
However, I do have to speak against the approach taken by many "GUID"
programs -- to assign a unique numberical key, possibly using allocations or
random numbers, which contains no other information.
When you're looking to replicate or exchange data, there are 4 pieces of
extended "meta-data" you need to have for each row:
1) A row key
2) the table to which the row belongs
3) the server on which the "live" copy of the table currently resides,
i.e. the server which currently "owns" the row
4) an absolute timestamp of when the row was last changed
In situations like this (1) usually does have to be some form of numeric
(surrogate) key unless you'll take the trouble to use hashes, just for code
simplicity. But you want the other pieces of information clearly in the GUID
key; otherwise you need to do a lot of calculation and querying to figure
out, when Server 11 wants to update Row 283432 of Table "status", whether it
can be done locally or needs to be "exchanged".
--
Josh Berkus
Aglio Database Solutions
San Francisco
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2004-08-09 17:33 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2004-07-27 06:36 surrogate keys and replication. sad <sad@bankir.ru>
2004-08-09 17:33 ` Josh Berkus <josh@agliodbs.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox