Criteria for data synchronization

Question

Good morning, wanted tips for data synchronization criteria, let’s go to scenario.

Next I have a system with an administrative where register products, customers, users, releases permissions, product units, product stock and other data.

I have the PDV (Point of sale) I need it to work without network but there’s the thought that I had initially .

Sync all data to pdv from time to time..

but wait, what if I have 300,000 products, I’ll sync them all every 5 seconds? Never..

so I thought I’d check for the last change (altered attribute) every time you save a product or any other data that is synchronized with the pdv I play the current date and time in the changed attributeIt is based on the last

ultima Incronizacao < alteradoEm ----- I sync everything

save the date of the last

and bingo! improved ne?

but... what if the user goes back to the date of the pc and save a product .. hahaha screwed my life. =/

there and where I want to know what criteria to use to make a data synchronization..

here use sql server 2008

Answer 1

Well, following your idea is good but we settled otherwise here at the company,

We did so, we will have a table (pendant_sync) (int reference, int terminaloffline, int typeScriptonized)

reference and ID of the object I want to synchronize terimaloffline is the terminaloffile ID (explain below) typeScriptonized within the system it will be an Enum.. that tells the type of data being synchronized, example if it is 1.. is a Product , if it is 3 is a user, if it is 7 is one_product and so on..

Offline terminal what is it? Good offline terminal (I’ll give as example a pdv)

you are in the supermarket and starting the system deployment you install the administrative and the pdvs, To start a pdv you must have an Offline Terminal.. if you don’t have pdv you simply won’t exit the offline terminal selection screen..

Registration of the terminal offline.. could have an ECF already registered and linked to pdv if you know the port that sera can put here.. if you do not know ok of anything do not select in pdv.. a description for the offline terminal, synchronization time, is an attribute to tie pdv to a particular offline terminal,

when registering the offline terminal, you simply select it in pdv and bingo! a preconfiguration is ready.. supposing you signed in and missed the ECF port pdv.. will not connect but will show an option to put the correct ecf port.. you put (the synchronizer will send the port to the register on the server)

basically and this the offline terminal..

let’s go to the synchronization part

pendes_sync the table I informed you above...

when I register a product I will have to insert the reference (product id), idterminalOffline (if you have two terminals you will have to have two inserts one for each.. ) , type (an indicator that you are synchronizing a product)

the same process to change the product..

well then what happens. if you have two terminals.. will have two inserts one for each terminal

when pdv (terminal) synchronizes it will be based on this table.. take her data.. will see that there is pending product to synchronize.. picks up his id search it and updates/inserts the product in pdv.. and deletes the record from the pending table_sync that referred to this update..

and that’s basically what we think

if you have any idea where we can get better and welcome =)

Answer 2

General algorithm

Have a field versaoLocal and a field versaoRemota. Test if they are different. If different, need to update, if not, good are equal, nothing to do.

The specific algorithm is:

1. In a local data you update only the field versaoLocal.
2. Pull up all the records with versaoLocal != versaoRemota.
3. Each runs the update process
4. Each one, using the data in memory, ago versaoLocal = versaoRemota (if downloaded), or versaoRemota = versaoLocal, upload.

Timestamped

Testing by difference solves the issue of wrong clocks, timezones, daylight saving time...

You still run the risk of matching a local timestamp equal to a remote timestamp. Low risk, but there is. If using timestamps, set the maximum of millisecond decimals available.

rowversion, UUID, or triggers

Instead of relying on date/time, use another versioning source. Some databases provide type fields rowversion, that guarantee to that bank instance will always have a new number, no repetitions, with each UPDATE. You have SQL Server 2008.

In the absence of such use UUID that the language provides.

As an alternative, triggers in the database, which in any UPDATE increments the number versaoLocal of that record.

Again, just test by difference to know when to upgrade.