> Hi, all.
>
> the dbs of my costumer are organized in a
> Hub-and-Spoke scenario. The databases will
> all be replicated among each other.
>
> Because of records of the same table can be created in every
> database it is necessary to have a unique primary key for the
> records. My idea is to create a compound PK which consists
> of an ID which is specific to the database in which the record
> is created and a value created by a generator.
>
> My questions:
> 1) Is this a good idea or causes it problems?
> 2) Is it better to store the compound PK in a VARCHAR column (e.g.
> "1_45" with db ID = 1 and 45 generated by a generator) or to use two
> INTEGER columns and define the primary key as the combination of the
> two columns?
> - How will the use of a VARCHAR column as PK in my tables affect the
> speed of my queries?
>
> Any help appreciated.
>
> Regards
>
> Jürgen

There's been many discussions on this topic - so the first thing I recommend
you do is search this group at Yahoo on the word replication.
Secondly I would recommend you grab a copy of a good replicator engine from
the bottom of this page
http://interbase.dthomas.co.uk/
and have a look at how this example sets up a database for replication. It's
easy to follow and you might enjoy what the repl manager does for you.

On the topic of varchar and PKs I am of the following to use Integer as PK
you can use the compound type as you suggest to mark database installations.
Some people prefer GUIDs but they are rather large and hard to index unless
you use the "reverse" type. Varchars are not generally recommended for PKs
unless you go the GUID option, i.e. you really want a VARCHAR and you can't
stand the idea of integer or compound PKs.
But as I say there's plenty of good reading here on this topic.
Alan