John DeSoi <desoi@pgedit.com> writes:
> > If you need data to propagate from the clients back to the server then things
> > get more complicated. Even then you could side step a lot of headaches if you
> > can structure the application in specific ways, such as guaranteeing that the
> > clients can only insert, never update records.
>
> And even updates could be OK if the application can support the right
> partitioning of the data and only do it one place at a time. With some kinds
> of field based work it might be suitable to have global (read only) data along
> with data created in the field that is site/ client specific. As long as the
> data collected in the field is not being updated on the master, it could
> continue to be updated in the field and synced back to the master database.
Sure, though then you have to deal with what data to display on the client
end. The most recently downloaded master data or the locally updated data?
What about after you upload your local data when you're not sure whether the
master data has been reconciled? Not impossible but it would be more work.
But I find a surprisingly high fraction of applications are very amenable to
being handled as insert-only. A medical application strikes me as something
someone is all the more likely to be happy with an insert-only model.
So instead of allowing having remote users to modify data directly you only
allow them to "request" an update. Then when they look at the record it still
makes logical sense to see the old data, along with their "requested" updates.
Essentially, any replication system is based on insert-only queues. If you can
design the application around that you avoid having to implement some sort of
mapping to some hiding that.
--
greg