sql server - DB design for synced desktop application -


I am creating a desktop application that will run on multiple laptops. Whenever the user returns to the office and is re-entered, then he will need to sync to the central database.

My biggest problem of overcoming is how to design the database so that it is easily synced to the central database server. One of the major obstacles is trying to determine how to handle the keys, they do not duplicate in many laptop databases that they will use. For example, laptops say that a new customer enters the customer "Customer A" - using a unique ID, it can be assigned a customer ID of 20. The laptop enters 2 "customer C" - it can also specify an ID of 20 for that customer. When it comes time to sync, both customers are A & A. Ends with a duplicate ID on the C server.

Has anyone worked with this kind of app that has a great solution?

Options are:

  • Category of ID , Which are difficult to apply and enforce, are very difficult to manage, it is difficult to provision a new site / category and it is more difficult to deal with retired sites / categories.
  • The overall key , (siteId, EntityId) are better than the ranges, but advance design is required and the left key is not specified in all the indexes (site id) because Multiple / All Sites (Central DWS) can cause problems on the issues to be gathered.
  • GUIDs . They are perfect in theory because they guarantee uniqueness (they can dispute in theory, I am still seeing a true good dispute) in practice they have very bad clustered key options due to size (16 bytes) and fragmentation . Even so, they are very easy to get right from the overall key point of view.

Comments

Popular posts from this blog

asp.net - Javascript/DOM Why is does my form not support submit()? -

sockets - Delphi: TTcpServer, connection reset when reading -

javascript - Classic ASP "ExecuteGlobal" statement acting differently on two servers -