On Mon, 8 Mar 2010, Adam Thompson wrote:
I'm wondering why the push to move so much functionality into the DB
instead of using an ORM, which seems to be where you're headed anyway?
Or, to rephrase that: if you don't want an ORM in the Perl framework,
why are you trying to build one in the DB? I'm perfectly OK dealing with
relational data. In fact, one of the things that's attractive about
LSMB is the RDBMS back-end. With security implemented on a table and
column level, I can use whatever report generator I want to build custom
reports. Making me access everything through stored procedures
eliminates any value LSMB has over other accounting systems... at least
for me. If I have to connect as a fully-privileged user, I guess I can,
but doing an end-run around the app is something I associate with Inuit
products, not LSMB.
Since I find myself agreeing with this to a certain extent, I will chime
in on something I would have otherwise remained out of.
First of all, I will say that I am not clear on the programming for what
you are doing--have never worked with PSQL stored procedures, and don't
know how certain of the other language elements fit into this.
That said, it looks like what you just explained is an order of DB
obscurity beyond what has been done to date. What I mean by that, is that
the interface is getting further and further away from raw table access,
and in this case specifically is getting quite far away from it.
I understand your reasoning for moving as much as possible into the
database. I agreed with it in the beginning as a reaction to SL's
codebase, even though I have never been very comfortable with it, but I am
starting to wonder.
We have turned the database from a device for storing and organizing the
storage and retrieval of information, into a device for processing that
information in ways which are less and less apparent. In other words, it
has been made into a blackbox.
If that is not a description of an ORM, then what is?
For a commercial app with a true API, I probably wouldn't have a problem
with this idea. However for an app in which you intend people to be
writing their own frontends, extensions, interfaces, etc., and in which
you intend those extensions and such to interact with the database, is this
wise?
I could see it, maybe, if all database interactivity was handled through
an API. In that case you're not talking about database access any more,
but instead programatic access through an interface which requires no
direct knowledge of the storage backend, and in fact demands that one
never interacts directly with that backend. But that's not what's
happening here. The way I understand it, these procedures are obscuring
the database, from within the database. So you end up with something of a
hybrid condition.
That just seems...undesirable.
Now, given my disclaimers above, I recognize that I could be barking up
the wrong tree, and if so I apologize for wasting your time with this.
However Adam's comments reinforced what I had started thinking while
reading your original message--that being that "this strikes me as a
level of complexity and obscurity too far.".