Re: Can we go beyond the standard to make Postgres radically better?

On 2/10/22 23:56, Guyren Howe wrote:
> On Feb 10, 2022, at 17:06 , Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com> wrote:
>>
>>> But SQL is a terrible, no good, very bad language.
>>
>>
>> I cannot accept such a religious persecution of SQL without a
>> detailed explanation.
>>
>
> I feel like anyone who is defending SQL here isn’t aware of how much
> better the alternatives are, and how bad SQL really is.
>
> I mean: it’s hard to write, hard to read. It’s hard to generate. But
> that’s just the starting point.

OK. If there are better alternatives, I am sure you will be able to sell
them to the world. Establish a company and have a go at it.

>
> One of the worst things about it that I don’t see much discussed is
> that it imposes assumptions about the storage model that aren’t part
> of the relational model. Like heavyweight, hard to change tables with
> transactional guarantees and such. Don’t get me wrong, those things
> are great to have available, but I don’t need them all the time.

Storage model and implementation are not part of SQL for good reason.
Database vendors have different implementations. MySQL and Postgres are
different. MySQL storage engines differ among themselves. Both of them
are different from SQL Server which is in turn different from Oracle and
DB2. Storage model determines the implementation. When there is only a
single relational database vendor left in the market, then they can burn
their storage implementation into the language standard. Until then, the
more, the merrier.

>
> The whole NoSQL movement has been such a tragedy. Having diagnosed a
> problem with SQL databases, they threw out the relational model and
> very often reimplemented a form of SQL when they should have done the
> opposite. There is no reason you can’t have a relational database with
> an on-demand schema, with eventual consistency, with all those fun
> things that various NoSQL databases provide. Those storage models have
> their place, but the SQL standard says you can’t use them.
>
> But the biggest issue is the verbose, terrible, very bad query
> language. In the web development community where I spend my time, it
> is almost holy writ to treat the database as a dumb data bucket, and
> do everything in the application layer (even things like validations,
> even when that is a provably incorrect approach). Why? I think it’s
> because they’re used to working in a pleasant language like Ruby or
> Python, and they want to do everything there. And who can blame them?

As a database architect who has successfully bridged two very different
database systems, I can tell you that the application programmers put
the business logic into the application because they frequently don't
know what the options are. They know Java or Python and that's what they
do, period. That has nothing to do with SQL.

>
> But this is bad. Proper relational design can take over much (most!)
> of the design of a typical business app, with significant efficiency
> gains the result. But no *community* is going to choose that when most
> of the members of the community don’t want to learn SQL and who can
> blame them?
Business community which hires them to make efficient applications can
blame them. And frequently does so.
>
> Another issue: everyone thinks “relational” is the same thing as
> “SQL”. If we could get folks to break that association, then relations
> should be a standard feature of high-level programming languages, just
> as arrays and hashes are.
>
> Heck, give me a functional programming language with a good relational
> model, and I can implement OOP in that relational language without
> breaking a sweat.
>
> Software *should* be designed around a logical/relational layer with
> minimal occasional forays into Turing completeness where necessary.
> But no-one is even thinking about software like that because
> relational is SQL and SQL is awful.

There is such thing as "free market". If you offer them a better
alternative, people will come. You may be the next Larry Ellison. And
then again, you may be not. There is only one way to tell, and that's
not proselytizing on the Postgres mailing list.

--
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com