When I first read your description, I really liked the simplicity of what you described. Then I got to thinking about tables, and what you might want to do with them and it struck me that hashes seem like a fairly natural interface to them. Looking under cpan://Tie::*, I found the modules I listed and I scanned the pods and decided I couldn't tell from that whether they had everything your had or not, so I thought I would ask, and get the skinny straight from the horses mouth:)

I really like the OO-metaphore for accessing external data. I'm less concerned by the purely syntactic differences between the two interfaces than you are, both have a sufficiently OO-style for my tastes, and in many respects I prefer the somewhat simpler, more direct lvalue syntax of accessing the data. I don't see any reason why a tied interface couldn't make connections between tables automatically following a similar hueristic to that your module uses. It ought to also be possible to have the tied interface handle inflation properly, but that is speculation, and in any case, it would require modifying or subclassing those modules, and your already does it.

I've encountered, the 'problem' with nested ties before, and whilst I'm not positive that it can't be solved, I haven't done so myself, and I've seen it discussed other places, so maybe it cannot be (adequately) solved.

Your argument about tie requiring me to mix the interfaces for anything that goes beyond simple accesses to the data is a convincing one. That to used the mixed interface requires me to hold two handles to each object strengthens it.

I was going to ask if your module allowed me to "refresh" the interface mid-stream so that if a view was updated as a result of a triggered, stored procedure, the object you had built for that view would reflect the change--in which case, I think I would be totally sold on it--but MySQL doesn't support these features, so that's an academic argument.

As it is, I like the sound of your module. Anything that keeps SQL out of applications is a good idea in my book, and for the purposes you devised it, it sounds perfectly simple and useful.