• Lack of impatience (too much abstraction here, to my mind)
• Some people think that complex means smart...
• The bad implementation syndrom :
  Or "how a good idea (database independance) could lead to an absurd implementation"
  By duplicating existing mechanisms(database independant API), and allowing some limitations that ruin the whole benefit(the column dependance problem))
  
• Megalomaniac Lead Programmer:
  You know the one who uses a lot of buzz words (and a lot of accronyms : DFL/SAL for DB functions layer and SQL abstraction layer ;-)

It could also easily be a result of Object Orientied-itis. Such a scheme as you describe EASILY fits itself into someone making a class heirarchy of web sites.

In either case, inexperienced perl programmers or higher-ups non-programmers sound like the root cause.

It could also easily be a result of Object Orientied-itis.

It's been my experience that most attempts to build abstraction layers on top of SQL are initiated by the programmers themselves, often for just this reason. They (uh, "we", since I've done this too :-) see SQL as lacking in OO goodness, and want to impose our own abstraction atop it.

Perhaps this one of of those cases where there's a "I've implemented my own _____ abstraction" club. The existence of such a club would explain a lot of strange code.

This is a bit of an over simplification, but the design should be for change. Installed applications change, and requirements change over the development cycle. Change should be easy. So if a SQL table changes (column add/change/remove), or the tables are completely redesigned, how easy is it to change the application?

If a simple table change causes changes in all most of your layers that might indicate a design problem. I like the idea of generating columns lists from the db, but is it done at all levels?

Having a new column automatically added to an INSERT statement is great, but is it automatically added to the web form? If so, is the layout what you want? If not, how does the database ever get a value? And do you want to be automatically generating column lists in one part of your application, but not others?

To make a long story longer, given that it is in place already, the added complexity probably won't hurt you as long as you have the ability to hand-code the SQL statements that don't fit neatly into the schema. I actually do something similar for the maintenance part of my apps that only admin users see. But for end-users, presentation and details matter so much that hand-coding is more normal.

I posted a snippet a while ago that shows one method of generating an SQL INSERT statement from an anonymous hash and a table name, which is about as simple as you can get. Plus it does clever things to produce placeholdered statements and batched commits.

It really is a funky piece of code that serves me well. OTOH it only works well in a limited domain, that is, it is not the ideal solution when you are inserting different columns sets at different points in the program (as it must generate a fresh prepared statement for each call and it's up to you to remember to tell it to do so).

So I think it would be hard to come up with something that satisfies the general case.

Plus, my main aim was to minimise characters. Not in a golf TM sense, but I didn't want to have to dick around with too many braces, parens or other syntactic fluff.

An example call looks like this:

    insert 'aglrelvalue', {
        att_value    => $id_mission,
        attribute_id => B0,
        client       => DEFCLIENT,
        last_update  => $mis_update,
        percentage   => 100.00,
        rel_attr_id  => YC,
        rel_value    => $regvp,
        user_id      => USER,
    };
[download]

what you have done is re-implement the DBIx::Recordset Insert() API function.

Man I hate when that happens.

--
g r i n d e r