Re: The tragedy of SQL

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: The tragedy of SQL
Дата
Msg-id CAHyXU0ym+E+6=rQ_bRUSDCU3pE67hEupqqZBPRjybwZ7jYZtTg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: The tragedy of SQL  (FWS Neil <neil@fairwindsoft.com>)
Ответы Re: The tragedy of SQL  (FWS Neil <neil@fairwindsoft.com>)
Список pgsql-general
On Tue, Sep 14, 2021 at 3:16 PM FWS Neil <neil@fairwindsoft.com> wrote:
>
> > On Sep 14, 2021, at 11:10 AM, Michael Nolan <htfoot@gmail.com> wrote:
> >
> > I started programming in 1967, and over the last 50+ years I've programmed in more languages than I would want to
list. I spent a decade writing in FORTRAN on a GA 18/30 (essentially a clone of the IBM 1130) with limited memory
space,so you had to write EFFICIENT code, something that is a bit of a lost art these days.  I also spent a decade
writingin COBOL. 
> >
> > I've not found many tasks that I couldn't find a way to write in whatever language I had available to write it in.
Theremay be bad (or at least inefficient) languages, but there are lots of bad programmers. 
>
> Yep, me too.  I would say that SQL has not achieved its design goals yet.  The original concept was to write what you
wantto achieve and have the server figure out the best way to get at it. 
>
> What people hate about SQL is that the programmer has to optimize SQL to get acceptable performance.  And the
optimizationis different for every implementation.  I think SQL has not hit its stride yet.  When the common $1000
serverhas 1024+ CPUs and 1+TB memory, and SQL implementations have adopted good multithreading architecture with access
to1024+ CPU dedicated AI engines, etc. a lot of the crap associated with performant SQL will go away. 
>
> At this point, I think it will be smart to strip out implementation details that have made it into the SQL syntax.
Therewill no longer be a need for it. This will make the SQL language simpler and easier to use, understand, and reason
about.

I think you ought to recognize that many people on this list make
money directly from managing that complexity :-).

Processing time remains bounded, and for complex queries how much time
is spend executing vs planning is a very difficult tradeoff.  Just
like in math, there are many ways to describe the same thing, and it
is for the clever to pick the best ones that run efficiently and well.
And thank goodness for that; it sends my kids to college.

Relating to your other point relating to implementations, it's not
different than having different browsers that render html and execute
javascript.  Having several high quality implementations to choose
from is healthy and good, and allows choice best on cost and feature
needs.  I would personally be much more inclined to gripe about
implementations that do not support standard syntax or have other
major standards issues (SQL server, I'm looking at you).

merlin



В списке pgsql-general по дате отправления:

Предыдущее
От: Ron
Дата:
Сообщение: Re: Alter and move corresponding: was The tragedy of SQL
Следующее
От: Gavin Flower
Дата:
Сообщение: Re: Alter and move corresponding: was The tragedy of SQL