Lead an application to data: drink faster

In a recent Dr. Dobb's Journal piece, Jim Starkey (senior architect for MySQL ) acknowledges that it's time to embed the power of applications within databases, instead of the other way around. Jim says (italics added by me):

I think we can agree that context switches or network round trips are bad things for application performance. On the other hand, modern database engines are getting quite greedy about memory and processors, so having lots of embedded database instances floating around a system doesn't make all that much sense. Rather than embedding the database engine in the application, wouldn't it make sense to embed the application in the database server? A bunch of happy applications each doing super-fast in-thread queries in nice sandboxes disgorging their results in a single blast of data is a pretty good way to structure things.

Well, where have we heard that before? SAS is ready to embrace this approach with its SAS In-Database Processing initiative.

In the past, I've used M&Ms illustrate how expensive it can be to move data around to facilitate analysis. The moral: what's the most efficient way to get data to a place where you can analyze it? Arranging it so that you don't have to move it at all, of course.