Re: The tragedy of SQL

On Tuesday, 14 September 2021 14:06:13 BST Merlin Moncure wrote:
> On Tue, Sep 14, 2021 at 12:32 AM Guyren Howe <guyren(at)gmail(dot)com> wrote:
> > If I had $5 million to invest in a startup, I would hire as many of the
> > core Postgres devs as I could to make a new database with all the
> > sophistication of Postgres but based on Datalog (or something similar).
> > (Or maybe add Datalog to Postgres). If that could get traction, it would
> > lead in a decade to a revolution in productivity in our industry.
> I've long thought that there is more algebraic type syntax sitting
> underneath SQL yearning to get out. If you wanted to try something
> like that today, a language pre-compiler or translator which converted
> the code to SQL is likely the only realistic approach if you wanted to
> get traction. History is not very kind to these approaches though and
> SQL is evolving and has huge investments behind it...much more than 5
> million bucks.
>
> ORMs a function of poor development culture and vendor advocacy, not
> the fault of SQL. If developers don't understand or are unwilling to
> use joins in language A, they won't in language B either.
>
> merlin
Back in the day, within IBM there were two separate relational databases. System-R
(which came from San Hose) and PRTV (the Peterlee Relational Test vehicle). As I
understand it SQL came from System-R and the optimizer (amongst other things) came
from PRTV.

PRTV (https://en.wikipedia.org/wiki/IBM_Peterlee_Relational_Test_Vehicle_(PRTV)[1]) did
not use SQL, and was never a released product, except with a graphical add-on which was
sold to two UK local authorities for urban planning.

So there are (and always have been) different ways to send requests to a relational DB, it is
just that SQL won the day.

--------
[1] https://en.wikipedia.org/wiki/IBM_Peterlee_Relational_Test_Vehicle_(PRTV)