Db synch - need advice - Mailing list pgsql-novice

From Didier Gasser-Morlay
Subject Db synch - need advice
Date
Msg-id AANLkTinpcymCUSSnZRraHESD2iwy_X5dvPu3gmLP+=AU@mail.gmail.com
Whole thread Raw
Responses Re: Db synch - need advice  (Jens Wilke <jens@wilke.org>)
Re: Db synch - need advice  (Mladen Gogala <mladen.gogala@vmsinfo.com>)
List pgsql-novice
Hello,

I need a bit of advice for the following problem as I do not know where to start.

My client has a sales prospection database in the office. each salesperson has access to it's own clients and prospects inside the company wide database. The sales director has access to all the prospects and clients. So far it is fairly simple.  

Now the sales manager wants each sales each sales person to have a netbook with a copy of the /subset/ of the client database he deals with, (in total around 20 tables) along with his agenda etc ... during the week, whilst travelling from client sites to client sites, the sales person can write reports about his visits (these are indexed in the database), amend the client/prospect database (add contacts, amend contacts, add notes ....)  upon his return to the head office, the sales person 'plugs' his netbook to the network, press the 'synch' button and pooof all by magic all changes made locally are merged with the central database, taking into account any changes made to the central database. Once this merge process is finished, the sales person netbook is refreshed with a copy of the new database fragment he deals with. 

Note that there are some update rules (like who owns the propect/client record in case of update conflicts). All primary keys for all records are numerical ids, handled by sequences. 

Instead of reinventing the wheel I thought I would ask what you all reckon  would be the best strategy  

- to merge the changes (updates and inserts) back to the central database, baring in mind that the central database may have also be updated and so there may be primary key conflicts which needs to be dealt with automatically.
- to extract the portion of the database the sales person needs to get. (he cannot have the full database at any one time for security reasons and since he uses a notebook, the speed is good but not great, so I can't really restore a full dump and then delete what the sales person does not need ) 

- all of this, of course in a reasonably short amount of time. 

I am open to any suggestion, my goal being to have something simple, and reliable. 

I would like thank in advance any of you that will go through the trouble of answering my questions

Didier

pgsql-novice by date:

Previous
From: Nima Ghorbany
Date:
Subject: Table access in postgres
Next
From: Thomas Kellerer
Date:
Subject: Re: Table access in postgres