There seem to be a few problems with the tied hash approach. For inflating foreign keys and other functions, Tie::Table is forced to mix OO/hashref metaphors (Tie::DBI doesn't seem to support foreign key inflation which really limits the comparison). From its POD:

  %company_14_users = %{ $company->{14}->user };
  ## [blokhead: it's not clear whether %company_14_users is magical or
+ not...]

  $company->{14}->{tax_num} = "111-22-3333";
  $company->{14}->write;
[download]

  $company_14 = $company->{14};
  $company_14->{tax_num} = "123456";

  # Wrong example:
  # $company->{14}->{tax_num} = "123456"
  # This doesn't work, because it always create a new Row object,
[download]

The only thing I can see in favor of having objects as hashes is for quicker glueing with HTML::Template. Of course, I could always add a ->to_hash method to my objects as well ;)

Also, one of my key reasons for doing this module is so that I never have to tell some interface about how my tables are related. With those modules, you have to set up a tied hash for each table, telling it about your primary key and foreign keys. Obviously you could make a wrapper to scan your database and build the appropriate tied hashes, but if my module can do it out of the box, why not? I know there's nothing earth-shattering about this idea, but it's saved me a lot of time along the way.

blokhead

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.

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.