Forum

[jtara]

XML is almost certainly overkill. Not sure why everybody is so XML-crazy. XML is slow, difficult to parse, and bloaty.

CSV is light and simple. With XML you are sending several times the number of bytes over the air. (Unless you compress, in which case the advantage of CSV may be minimal in terms of bytes transmitted, as XML's bloat is primarly in redundancy.)

You can use a timestamp, or you could use revision numbers. You might prefer a timestamp, because it might be useful for internal auditing. But a revision number is lighter. The revision numbers would have to be GLOBAL within the database, just like a timestamp would be. (That is, not "revision 2 of record 10", but revision 2, period. Each record changed increments the global revision number.)

You need a table in the database that keeps track of the highest revision number (or timestamp) that each user has. Or you could keep track of that in the client.

Updates and new records are easy. Deletions are a bit more complicated, but not very much so - you can't ever really delete a record on the server. Have a "deleted" column in the master database. When you "delete" a record, you set the deleted column true, and the client needs to know when it gets an update, if the deleted column is true, to delete the record. (You CAN delete records on the client side, just not on the server side.)

When the client makes a request to the web service for an update, the server will do a database query for all records with a revision number (or timestamp) greater than the largest revision number/timestamp which the client already has.

There you go, there's your sync. Or, actually, replication.

Now, did you really mean "sync", or just "replicate"? Because if you meant "sync" that is more complicated. That is, will clients be making changes to the database, and those need to be uploaded too?