Proposed New Name for DB access architecture

["Chris Travers" <..hidden..>]

Hi all;

I have been thinking about various objections to calling our
stored-proc-discovery-based relation<->object interface an ORM.  The
basic thing is that we are not really doing ORM stuff even though we
are tackling the same impedance mismatch issues that ORMS have to deal
with.

Also, I suspect that treating this as an ORM creates an opportunity
for the abuse of stored procedures beyond what they are really
supposed to do.  If we take it too far, we could eventually find that
we are having the database do things that it really should not be
required to do.  As a result, I am going to propose a name for the use
of discoverable stored procs for db access as: SODA (Service Oriented
Database Architecture).  People know know me know I don't make
buzzword compliance a goal at all, but in this case I think it is more
clear because:
1)  This really is an application of service oriented principles
(namely the focus on discoverable remote procedure interfaces) to the
database interface architecture
2)  It is almost entirely unlike an ORM in that we map to functions
rather than relations.

As a bad pun, since Perl doesn't do any strong typing, we could call
this process SODALite (a soft bluish rock sometimes sold at rock
shops)....

Any thoughts?
Chris Travers