Re: database distribution/replication

"Jens" <axvkkkclbcqg_at_spammotel.com> wrote in message <news:vImTVl25inkn-pn2-HFdOjDskoXYe_at_jms.xww.de>...

> "Tobin Harris" <comedyharris_at_hotmail.com> wrote:

> > Does synchronising your organisatinos data hold any business value, and if
> > so can you fight for some budget to buy the tools?
>
> MQSeries for example is very expensive if we have to buy it for every
> office.

Heh. The costs of writing your own could well end up being 10x the cost of buying off-the-shelf, and that's only if the project even finishes...

> > If you're stuck with your own format, then you might have to write your own
> > engine. You could also consider writing export/import routines to a
> > commercial database and using that only for replication ( a kind of
> > operational data store).
>
> We have good developers. Thats not the problem. We like to do it. But
> I'd like to have some ideas (not solutions) from other people how to
> implement it.

Your biggest problem will be update conflict resolution. What should happen if, say, both the head office and a branch office have changed some of the same records? What if one office changed only fields A and C, while the other changed B and D, can the changes be integrated? What if they both have changed the same field within the same record? What should happen when two offices insert records whose keys collide when you attempt to merge them at your main branch, or if one branch inserts or updates a record which collides with a record updated by another branch? Can there be a one-size-fits-most approach, or would your strategy drown in a combinatorial explosion of "business rules"?

--
Joe Foster <mailto:jlfoster%40znet.com>     Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!