This is quite a brilliant little idea. A couple of years ago I was involved in a newspaper project (Boston.com) that used Squid with ESI to build the page from disparate Zope backend servers, and it resolved quite a lot of problems--like being able to have a fast and database-less server in the front that could make decisions about which backend servers to draw from based on the required content. The backend servers then didn't need full copies of the database, because they would only ever be asked for content they were authoritative for.
DBSlayer takes the web server and the proxy server out of the picture, and puts the site building burden (to some degree) on the client. It could, theoretically, also make decisions about which database to query, such that the memory caches on the database servers will always be primed with the content that the database is authoritative for.
The comments so far seem concerned about security...but DBSlayer wouldn't need write access, or access to all tables. It could simply be a read-only window into some tables. I guess that's a foreign notion to folks who do everything in one process, which has to have write access...but it's one of the aspects of proper databases that makes them useful in large scale deployments.
I do think there would be serious security implications in exposing read-only access to even a limited number of tables via arbitrary queries from clients. DoS would be trivial and unexpected data leaks easy. Having to explicitly expose parts of your data only as you intend is a great security precaution (and good use of abstraction).
But I don't think the intended use is to have client browsers hit DBSlayer directly. My understanding is that you send SQL from your app layer via HTTP to DBSlayer then it hits a DB and returns JSON.
DBSlayer takes the web server and the proxy server out of the picture, and puts the site building burden (to some degree) on the client. It could, theoretically, also make decisions about which database to query, such that the memory caches on the database servers will always be primed with the content that the database is authoritative for.
The comments so far seem concerned about security...but DBSlayer wouldn't need write access, or access to all tables. It could simply be a read-only window into some tables. I guess that's a foreign notion to folks who do everything in one process, which has to have write access...but it's one of the aspects of proper databases that makes them useful in large scale deployments.