From: Josh Berkus <josh@agliodbs.com>
To: sad <sad@bankir.ru>
To: pgsql-sql@postgresql.org
Subject: Re: surrogate keys and replication.
Date: Mon, 9 Aug 2004 10:33:47 -0700
Message-ID: <200408091033.47934.josh@agliodbs.com> (raw)
In-Reply-To: <200407271036.49581.sad@bankir.ru>
References: <200407271036.49581.sad@bankir.ru>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: josh@agliodbs.com, sad@bankir.ru
Subject: Re: surrogate keys and replication.
In-Reply-To: <200408091033.47934.josh@agliodbs.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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