Sujet : Re: VMS x86-64 database server
De : arne (at) *nospam* vajhoej.dk (Arne Vajhøj)
Groupes : comp.os.vmsDate : 09. Jul 2025, 01:31:37
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <104kd99$3r3fk$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12
User-Agent : Mozilla Thunderbird
On 7/8/2025 7:37 PM, Lawrence D'Oliveiro wrote:
On Tue, 8 Jul 2025 18:20:50 -0400, Arne Vajhøj wrote:
Standards evolve. They add lots of new stuff. And sometimes they remove
stuff that is not needed anymore.
But those standards in particular have not evolved.
SQL standard has evolved. Lot of stuff has been added.
1987/1989 -> 1992 -> 1999 -> 2003/2006 -> 2008 -> 2011 -> 2016 -> 2019 -> 2023
The SQL standard is organized in parts.
Part 2 is native languages embedded SQL.
Part 3 is native languages call API.
Part 10 is Java embedded SQL.
Part 13 is SP/UDF in Java.
They could have deprecated part 10 in maybe 2011 and removed
it in maybe 2019.
But they did not.
Embedded SQL in native languages is still needed.
It is still just as clunky an idea as it was when first proposed.
For traditional procedural native languages it reduces code
size for database code with 10-50% compared to call API and
I would say that readability is even more improved, because
the lines saved (typical binding calls) are sometimes very
complex to handle all sorts of cases.
So embedded SQL makes perfect sense in that context.
Modern high level languages usually require a lot less plumbing code,
so they don't need embedded SQL.
And an OO language with ORM is requiring way less code than both
call API and embedded SQL.
But as long as there is a need for traditional procedural native
languages to do database access, then embedded SQL makes sense.
Arne