i've not used matt's sql module itself (i should check it out) so i can't comment on his implementation, but... SQL is really ugly. it's not hard to construct something that provides the same functionality in a much more palatable form. aesthetics aside, if you're dealing with a database-heavy app, it can make the code much easier to read.
somewhat harder is creating such a module in a way that's not specific to a specific database, or even sql. this is similar (in theory) to what the various php database modules do. this can be important if your application is delivered/deployed in an environment where you don't have control over what database is being used (although if the database is important for your app, i think not having control over the database is a poor position to be in). not any harder but a lot less general is the option of wrapping the database around a higher-level abstraction. you can do things like data constraints and validations in the application code, rather than in the sql database itself, which always feels like this random bolt-on to the application logic. in the last large database-centered project i was involved in, owing in large part to the lead programmer's linguistics background, we called this the ontology layer: it defined the things that exist. the rest of the app only had to deal with what was in there, and it took care of mapping things to a backing store. at the layer of ontology, a fs-like interface can work pretty well. i'm less convinced it's worth doing much with a lower-level database beyond a slightly smart data channel.
