From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Mike Sofen
I disagree. I’ve worked as database architect/engineer at a number of large and small firms in various verticals (healthcare, financials, insurance, aerospace, telecom, etc), and created complete database api’s via stored procs/stored functions, some of which were quite complex. I’ve found that a mid-level database developer, with modest coaching and good comments in the code, can pick up the code, support it and even enhance it. So the notion that experts can only write and maintain quality code isn’t valid in my experience.
The original proposition was that this (a stored procedure API) was such a simple task any beginner could do it with ease. My view is that it is a job for a seasoned application developer with SQL skills that go well beyond simple queries. I don’t see much disagreement here.
There is definitely a difference in capability/velocity/solution solving between junior, mid-level and senior developers, but that isn’t a deal killer, it’s just something that needs to be managed and accounted for.
One reason for a database api is that ORMs have proved themselves incapable of proper scaling and ACID compliance, where stored procs/functions are capable of leveraging the massive set-based relational power of the underlying engine, and leverage efficient functionalities like windowing functions.
I agree absolutely. ORMs exists because of a strong desire to do business logic coding in the big 5 OO languages and not in whatever dialect of SQL may or may not be available on the RDBMS in question. The whole point of Andl is to make set-based relational logic including user-written accumulation functions, recursion (CTE) and ordered queries (windowing) available and accessible to ordinary developers, and totally avoid the need for an ORM.
So I guess you’d say I’m in the entirely opposite camp, since it’s proven to be such an effective solution architecture for many applications that leverage relational database engines.
It is indeed a totally effective architecture. If you haven’t already read it I strongly recommend http://thehelsinkideclaration.blogspot.com.au/2009/03/window-on-data-applications.html fora detailed description. It’s effective, but it sure ain’t easy, especially if you value portability between RDBMS. Andl aims to fill that gap: make that architecture accessible to all.
I don’t think we’re in different camps at all.
Regards
David M Bennett FACS
Andl - A New Database Language - andl.org
