From: dandl Sent: Wednesday, May 04, 2016 5:05 PM
To: 'Pierre Chevalier Géologue' <pierrechevaliergeol@free.fr>
> From: Pierre Chevalier Géologue [mailto:pierrechevaliergeol@free.fr]
> ...
> > Then I think you've seriously misunderstood. Most people can indeed
> >learn to write basic SQL queries, but those are
> >(obviously) not what I'm talking about.
> >
> > To write the business logic of a significant application entirely in
> >SQL requires PLSQL (or in other dialects, whatever passes for SQL/PSM).
> >It means writing an entire data access layer as a set of stored
> >procedures, with a substantial set of special functions, types,
> >triggers and so on. No beginner and few experts have the skills
> >required to do that in SQL, and then debug that code on the server.
>
> All right, I understand better now. I think I also totally missed
> your point, sorry...
> I'll give a look at andl.
I hope you do. Please feel free to contact me with any comments, suggestions, etc.
I have not completed the Postgres implementation -- probably another couple of weeks –
but in-memory and Sqlite are there.
Bonne chance!
Regards
David M Bennett FACS
=======================
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.
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.
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.
Mike Sofen (San Diego, CA USA)
