Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Quick note - if I'm rambling below, I'm sorry :) Please ask for clarification and I will try.</p> <p>If all you want to do is replicate data, then you can use the inbuilt functionality provided by a database system. However, these are usually aimed at creating an exact copy, with no provision for any smarts (adjusting stock levels, for example).</p> <p>The easiest way to do this and allow for smarts is to provide a way to handle events. An event can be whatever you decide is required, for example an order being placed against a stock item, and usually has an event type to specify what that event means. Importantly, an event has a timestamp. This allows you to decide which events are relevant when you synchronise your device back up to the central hub. It also helps you resolve conflicts when events are generated on both sides for the same thing.</p> <p>Importantly, if you can define the events that can occur from both ends, and their scope, then it makes it easier to identify and resolve these conflicts. It also helps to decide what information you need to resolve them, whether a simple timestamp is enough or some sort of priority system (ie. a change on the main server takes precedence). Also, whether they need resolving at all, or whether events can only be processed one-way.</p> <p>When you connect the device, you process the events that have occurred since the last time you connected. This can allow you to customise what events are processed where (main system or mobile device), and the effects they produce. Importantly, to keep things simple, events only need to be generated for things you can change on the mobile device.</p> <p>From your example, synchronising stock lists, customers, and all that other stuff is a straightforward replication of data to the mobile device, and could possibly be handled by some sort of automatic replication, though you would have to be able to specify the information to replicate (as you don't want an exact copy of everything).</p> <p>The mobile device would then generate events onsite when creating an order or something like that. These events would tell the main system that an order has been created/cancelled/etc. You would also include a table to specify the products and quantities that were ordered/cancelled.</p> <p>When you sync up, the mobile device uploads it's events, and the main machine processes them and works out any conflicts with its own events. It then allows the client to download any relevant events that might affect items it already contains (or it may not, and just repopulate the device with new data, depending on the complexity of the system).</p> <p>There may be other things like changing customer information onsite or whatever, but again that is primarily a straightforward data sync, though you may wish to create an event to say that it has happened to decide whether to change the customer info in the main system (as it might have also been changed by someone else...)</p> <hr> <p>As an example, a company I used to work for developed a mobile system for customer service representatives repairing widgets. They may not even live in the same state as the main system. In the morning, the customer service person would turn on their laptop, synchronise to the main system and receive updates for their jobs that day in the form of events. This might include new jobs, or a status update saying the job had been cancelled, redirected to another representative, rescheduled, whatever. These are generated by someone at head office (usually) who's taking phone calls and updating the system through some sort of interface. We didn't even know what that interface was, just that it produced certain events in the database that we could use.</p> <p>When an event was generated specifying a new job, that's all it did. The job details, including customer and widget information, was all a straight sync to the device. Importantly, part lists and all that stuff were only synced one way, TO the mobile device.</p> <p>When they turn up to a job they mark it as commenced, do their thing, ordered required parts if they are missing something, mark completed, whatever. This happened offline, and generated events on the mobile device.</p> <p>At some point, the representative would connect and do another sync. This would process the events created on the mobile device, working out any conflicts, and then allow the mobile device to update itself with new events from the main system. Importantly, the conflict resolution was restricted to what events happened when - obviously if the representative had fixed the widget, then any cancellation of the appointment was irrelevant. Also, if they required parts, this was a straight sync of data, simply telling the main system to order those parts, but this would not happen without an associated event.</p>
    singulars
    1. This table or related slice is empty.
    1. POIs DB Replication a proper solution for this scenario/problem?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USMattJenko
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload