DB synchronization problem

Hi,

We are dealing with a large gas supplier company which has gas
distributors in cities, towns as well as remote villages. The gas
distributors may or may not have a broadband connections. They have to
synchronize their local data with central server data and also receive
latest updates from the central server.

The central headquarter systems would want to know the new customers
who have registered and assign each one a unique ID. These unique IDs
should then be sent to the local systems. Also, they would want
reports of the stock available at each distributor and the consumption
rate, so that they can plan the supply. The upload would typically be
reports of what new customers have registered, what revenue has been
collected, what is the supply backlog, etc. The data downloaded would
be rates, master info like regions, etc. Locally the application will
be on during business hours or may be running round the clock.
Connectivity to the central servers can be throughout the day or
intermittent.

The local systems should be capable of working on Win/Linux/Unix.

We can assume 300-400 transactions at each distributor on a daily
basis.

We need to decide on which database system is to be deployed at the
local stations and what technology can be used for communicating
between the local and central systems.

If there are changes in the local DB structure, how would they be
pushed to the local systems?

What design options do we have to achieve this?
Any third party tools are available for doing this?

I am working from rough specs and am looking for alternatives/links/
patterns that members of this group may be aware of.

Thanks,
Yash

On Aug 26, 8:30*am, Yash <yas...@gmail.com> wrote:
> Hi,
>
> We are dealing with a large gas supplier company which has gas
> distributors in cities, towns as well as remote villages. The gas
> distributors may or may not have a broadband connections. They have to
> synchronize their local data with central server data and also receive
> latest updates from the central server.
>
> The central headquarter systems would want to know the new customers
> who have registered and assign each one a unique ID. These unique IDs
> should then be sent to the local systems. Also, they would want
> reports of the stock available at each distributor and the consumption
> rate, so that they can plan the supply. The upload would typically be
> reports of what new customers have registered, what revenue has been
> collected, what is the supply backlog, etc. The data downloaded would
> be rates, master info like regions, etc. Locally the application will
> be on during business hours or may be running round the clock.
> Connectivity to the central servers can be throughout the day or
> intermittent.
>
> The local systems should be capable of working on Win/Linux/Unix.
>
> We can assume 300-400 transactions at each distributor on a daily
> basis.
>
> We need to decide on which database system is to be deployed at the
> local stations and what technology can be used for communicating
> between the local and central systems.
>
> If there are changes in the local DB structure, how would they be
> pushed to the local systems?
>
> What design options do we have to achieve this?
> Any third party tools are available for doing this?
>
> I am working from rough specs and am looking for alternatives/links/
> patterns that members of this group may be aware of.
>
> Thanks,
> Yash

To answer you questions requires more space than a newsgroup post.

The local DB could be commercial or one of many open source and/or
freeware DBs. A little more requirements work might need to be done to
get more specific. e.g. what do your developers have experience with?
what application languages/tools do you plan to use? Do you need a
DBMS(transactions, relational model, etc.) or just a File server or
something in between? I would not suggest one with out more
information.

I will say your critical issue is slow connections. You cannot
reliably assign a central account ID to the customers if the
connection is not reliable. If you would like more input, contact me
offline.

Ed Prochak
Magic Interface, Ltd.