views:

68

answers:

1

Hello there,

We have a local server with an access database which feeds data to clients in the same domain. Now we also have a website which is hosted externally, and working on a bridge system to provided upload/downloaded functionality of products, categories and orders etc.

Products, categories and customers etc. can only be added locally, however, orders can be added both locally and on the website. We are trying to have these synchronised by the bridge application which uses Web Services. We have had this working but have come across more issues. Our current approach is:

  • Every individual record has a local id (luid) and a web server id (suid), one example of usage is when an item is added on the website, it is given a unique suid and the luid is -1, once the item is downloaded by the bridge application, an luid is applied and updated. This is the inverse for items added on the local server.
  • Every indivdual record also has a flag field (highlighting insert, update, remove(from the website) and delete).

The above works well - apart from the luid and suid approach has made it impossible to easily track record relationships once an item is downloaded. This approach only seems to work well for one-way data - i.e. just uploading products to the website for viewing (and updating and removing them dynamically).

To solve this problem I have considered using GUIDs or perhaps COMBs GUID approach which means that items can be added on both sides and synced appropriately, thought the performance hit concerns me slightly.

Some important points are:

  • The local server is the data "base camp" where everything needs to be (eventually) stored.
  • Only the local bridge application can make requests to the web server due to web services.
  • Needs to support the chance the there may not always be an internet connection, so requesting unique IDs from the web server is not ideal.

Does anyone have an opinion on a much better programming approach to handling this sort of 'synchronisation'?

Kind Regards,

Tony

A: 

A unique id is surely going to simplify things. I don't see why you need to be concerned about performance, the GUID can be constructed from something machine-specific or ids can be issued in tranches so that normalid construction is a purely local activity.

djna
My performance concerns were purely as the web site will use these GUIDs in joins when the website is being used. Do you still feel this is not an issue?
Tony Day
Comparing using GUIDs or your current ids? Key size is larger for a GUID and hence worse performance? My instict would be that performance impact is tiny, but as with all things performance-related the on;ly way to really know is to measure. Doing a complex design in order to avoid what transpires to be a trivial performance overhead is an all too common mistake.
djna
I will probably do joins on the GUIDs avoiding having to set local and server ids as they are synced, and relate them separately. I will do some performance tests with GUIDs and relationships with the suspected table sizes.Thank you very much for your input :)
Tony Day