NYCPHP Meetup

[Hans Zaunere]

> > You may want to consider using web services.  Data would be stored in a
> > local MySQL database, and then as you mention, a central server aggregates
> > the data from all the locations.
> >
> > The reason I mention web services, is that HTTP is typically more robust
> > over flakey connectivity than database protocols are.
> 
> Hans, have you seen something like this in production? It seems like a
> great open source project that could become part of MySQL's lineup,
> for use in exactly the type of situation that Allen describes.
> 
> MySQL Master <--> HTTPS Transaction Broker <--> Remote MySQL Cache
> 
> It's kind of the same architecture that Gears wants to put you in on
> the client: you keep a local copy of all the data that's important to
> you, synchronized whenever you are online with the main database. The
> pattern is everywhere, but I've never seen a tool that was
> purpose-built to do this between MySQL instances.

I haven't seen a general purpose tool for this type of thing, but have seen the same architecture done in a couple of places.  For example, desktop patch level tracking and location tracking for trains.

The caveat to all of this is the complexity of the data.  As data increases in complexity, conflict resolution gets more difficult on the aggregating web service.  And perhaps more importantly, the actual XML/POST/GET/etc actions that transmit the data between remote and central location can grow quickly and be complex to parse/structure themselves.

But as you mention, the pattern is good/growing, and useful wherever connectivity can't be guaranteed, or is known to be intermittent.  HTTP is a good fit because of its asynchronous nature, whereas database protocols are often latency and connectivity sensitive.  But with a flexible framework, the purpose specific logic could be dropped in where needed, and this would be an interesting project.

H