Yes a Tied interface is what is called for here (two Tied interfaces? one for the database lookup of a table (since there can be only one table of a given name in a database) and one for a table lookup of a row) but the requirement for composite keys makes the behavior quite a bit different from Tie::DBI.

An extreme simplification of the Tied interface would make the first level of hash specify the database server type (ie: server=>'dbi:mysql'), the second level hash specify the credentials (ie: {user=>..., password=>...}), a third level specifying the database name (ie: {$database_name=>{...}}) and then the rest of the hashes behave as previously described for tables and fields.

Also, if something is underspecified, it might return an array; but if it worked that way, the row and field hash interfaces would have to always go through an array ref, ie:

$baz=$object->[0]->{baz}->[0];
$qux=$object->[0]->{qux}->[0];
[download]

Blech... But I suppose the schema could restrict that mess to when that level of indirection was required.

Finally, I suppose insertion of a row could also take the form of a 'new' method on the table:

$table->new({baz=>$baz,$qux=>$qux,...});

And if there is an autoincrement key (like 'id'), leaving it out would imply its value to be the next incremented value of that field for that table.