banksyw

Disclaimer: I wrote that article.

Percona toolkit has some useful stuff. Thanks for the link.

In this case our solution ended up being pretty much the same as pt-table-sync except that it made use of our distributed task queuing system so was MUCH faster than if we had used a single threaded perl script. (Up to a few hundred chunks of rows being checksummed/synced in parallel.) I didn't talk about this aspect directly in the article to keep it focused.

Not sure if it would be possible to use pt-table-sync in that way, certainly would have taken a lot more work to get a third-party perl script to distribute the work through our job queue.

With respect I think you have missed the point a little. The thing this idea solves is separating data-fetching optimisation from code layout. Regardless of whether you use MVC or entirely procedural code, it gets very hard to keep data access optimal when you have very complex and highly modular pages without introducing hacky globals or coupling unrelated parts of the code together (should be obvious why that's bad).

For any one page you may be able to change the structure so that it is more efficient without compromising the code too much but some of those modules will need to be reused in a completely different context on a different page.

I'm perhaps not explaining very well but this idea isn't solving deficiencies with MVC, it is solving a problem inherent in ANY attempt to modularise/re-use code. To gain the same data-access efficiency without MVC would leave your code unreadable not to mention un-maintanable with a complex site and high frequency changes.

Many sites simply don't need this so yes it would be overkill and of little benefit for them. I don't think the article was suggesting such a scheme would work well for everyone else. If you do have pages which legitimately need to make hundreds of queries/cache gets to resolve the data requirements though, techniques like this can help a lot.