Re: The tragedy of SQL

Поиск
Список
Период
Сортировка
От Guyren Howe
Тема Re: The tragedy of SQL
Дата
Msg-id 4B44C3F8-DC54-468A-9094-3AA3951613FC@gmail.com
обсуждение исходный текст
Ответ на Re: The tragedy of SQL  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: The tragedy of SQL  (Rob Sargent <robjsargent@gmail.com>)
Re: The tragedy of SQL  (Mladen Gogala <gogala.mladen@gmail.com>)
Re: The tragedy of SQL  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
Re: The tragedy of SQL  (Ron <ronljohnsonjr@gmail.com>)
Список pgsql-general
On Sep 16, 2021, at 7:31 , Merlin Moncure <mmoncure@gmail.com> wrote:

On Wed, Sep 15, 2021 at 7:31 PM FWS Neil <neil@fairwindsoft.com> wrote:
On Sep 15, 2021, at 2:44 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
I think you ought to recognize that many people on this list make
money directly from managing that complexity :-).

I did not intend to disparage anyone.  People, including myself, make money when they provide value and there is certainly value here.

But, I am not sure I understand your inference.  Are you saying (and I am not implying you are) that PostgreSQL does not progress in line with the original SQL goals of simplifying data access because people are making money off of the current complexity?

Not at all.  I'm saying that this mailing list is stuffed with people
that work on and with the database, and SQL is in many cases
(including mine) a passion.   Postgres is a technical marvel so that
we make money by utilizing it effectively, and rendering, er,
constructive feedback to its stewards so that it may improve and we
may all become more efficient.

Points made upthread suggesting SQL is bad due to being based on sets
were ironic IMO.  SQL is successful and enduring precisely because you
can direct operations by describing data relationships rather than
implement specific operations by hand.  Fluency in that technique
leads to solution achievement that other technologies cannot approach.
It rewards artistry and creativity, which I guess rubs some people the
wrong way since it does not align to factory development strategies.

No offense taken; I enjoy the debate; this thread is an indulgence,
being a bit of time off from capricious C suite executives, agile
methodology zealots, etc. So fire away.

Missing my original point here. The set theory is the _point_. SQL is a gargantuan distraction from using it efficiently. 

Imagine if COBOL was the only widely-available programming language with functions. You might use it, because functions are really great abstraction for programming. That wouldn’t mean that COBOL wasn’t an utterly awful language.

SQL is like that, only for relations, sets and logic.

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

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