Data synchronization

[Ruslan Zasukhin]

On 3/9/07 12:16 PM, "Thorsten Hohage" <thohage at objectmanufactur.com> wrote:

Hi Thorsten, 

>> And here main question we have:
>> 
>> Does laptops should have
>>     a) the whole snapshoot of server db ?
> 
> sometimes yes - it seems that especially germans tend to carry the
> whole 10GB DB with them, but ...
> 
>>     b) or its part?
> 
> yes - THIS is in most cases (system I build) used. But part often
> means depend on context i.e. a query what should be replicated (where
> staff_district = 'Hamburg') and it depends on the table, too. So
> articles complete, customers only from the district, help desk-tables
> none.

Right, each client should have set of own FILTERs. And as Bart point this
also help with security (e.g. Employers should not see what Managers can).
 

> Additional one further remark
> 
>>> Changes are synced when network is available.
> 
> perhaps not only when network is available. There are still
> situations where syncing should be done by media transfer, i.e. USB-
> Stick, CD, ... i.e. imagine a expedition where the entered data must
> be synced and NO or better NO cheap enough network is enable


-----------------
> And I want to add two more and really important topics! There must be
> a solution for generating unique-keys, too - something like satellite-
> id + table-unique-id to be able to sync data - enter new data on each
> system - re-sync - enter other new data ... could be tricky, really
> tricky.

Right. 

In MS SQL they use GUID for this.
Ivan like this solution the most as I see :-)
So our first step then should be adding this field type into Valentina.


> We used a system with a central serial table with pre-generated
> serials and an id for what satellite this id is. These serials are
> replicated, too and so every system gets its set of serials. Using
> triggers to request a serial when a record is generated. But of
> course there are several more concept on how to handle serials in a
> distributed system

Yes, pre-generated serials also used often. Although agree, this require
some special job on both computers to prepare them for replications.
Annoying. 

> The same problem is regarding deletion of data. Satellite_1 and
> Satellite_2 get some contacts in the same time. Now Satellite_1
> deletes a contact and Satellite_2 changes this contact later in time,
> then Satellite_1 deletes it. Satellite_1 syncs his data to server,
> later Satellite_2 syncs too and the contact is back. Next time
> Satellite_1 syncs with the server he gets the deleted contact back.
> 
> Other scenario: Satellite_1 and Satellite_2 gets both contact data,
> but Satellite_2 get the invoices, too. Satellite_1 doesn't see any
> invoices and deletes the contact, what happened with the joined data
> that are still on Satellite_2.
> 
> Of course some of these issues must be handled by application (better
> system) logic, but there must be propitiate options in the database
> to configure these rules.

These are "CONFLICTS". In the most hard cases human manual task required,
like when we have conflicts workings with CVS.

-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]