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

So to summarize, people are bad programmers who refuse to learn SQL So SQL
is the problem? Common. You cannot bring that to a postgres list serve.

Look. It's not perfect. It's a pain. It is hard to generate queries (oh my
God why are you doing this?) and it's hard to work with. You are describing
c++ to Python programmers and arguing why no one should ever use c++. And
look, there are other languages that are way better like Python. So why
would anyone ever chose c++?

Because the application is already in c++. Companies store petabytes of
data in SQL databases. With very simple commands, you can ensure that a
table with a billion rows has 10-way combination of unique values. Is FROM
X select Y better? Probably. Is print(x) better than cout << x.p() << endl;
? Yep. But it would take some serious guts to wander over to a C++ list and
explain how it is the worst language and needs to be scrapped and there are
way better languages out there.

Also, no one really argues for sql. We know it isn't great but we also know
why it likely can't change and it works.

On Fri, Feb 11, 2022, 9:26 AM Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com> wrote:

> 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-1217https://dbwhisperer.wordpress.com
>
>