We have a local server with an access database that transfers data to clients in the same domain. We now also have a website that is hosted externally and is working on a bridge system to provide downloadable / downloadable features for 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 synchronize them using a bridge application using web services. We had this job, but I had more problems. Our current approach:
- Each individual entry has a local identifier (luid) and a web server identifier (suid), one example of use is when an element is added to a website, it is assigned a unique suid, and luid is -1, once the element is loaded by the Bridge application, it is applied and updated luid. This is the inverse for items added to the local server.
- Each individual entry also has a flag field (highlight insertion, update, delete (from the website) and delete).
This works well - apart from the luid and suid approach, it was not possible to easily track record relationships after the element was loaded. This approach seems to work well for one-way data, i.e. It simply uploads products to the site for viewing (and updating and removing them dynamically).
To solve this problem, I considered using a GUID, or perhaps a GUID approach to COMBs, which means that elements can be added on both sides and synchronized accordingly, considering that performance affects me a lot.
Some important points:
- A local server is a base data camp where everything needs to be (ultimately) stored.
- Only the local bridge application can send requests to the web server due to web services.
- It is necessary to maintain the likelihood that there may not always be an Internet connection, so requesting unique identifiers from a web server is not ideal.
Does anyone have an opinion on a much more efficient approach to programming this kind of "synchronization"?