Re: The tragedy of SQL - Mailing list pgsql-general
| From | Guyren Howe |
|---|---|
| Subject | Re: The tragedy of SQL |
| Date | |
| Msg-id | 62d7895c-a008-4d48-94d5-48aeec23eaf5@Spark Whole thread Raw |
| In response to | Re: The tragedy of SQL (Mladen Gogala <gogala.mladen@gmail.com>) |
| Responses |
Re: The tragedy of SQL
(Raymond Brinzer <ray.brinzer@gmail.com>)
Re: The tragedy of SQL (Mladen Gogala <gogala.mladen@gmail.com>) |
| List | pgsql-general |
On Sep 14, 2021, 12:51 -0700, Mladen Gogala <gogala.mladen@gmail.com>, wrote:
Replies in-line
On 9/14/21 01:51, Guyren Howe wrote:They are making a decent decision. SQL is a *fucking terrible* language, which I don’t blame them for not wanting to learn.Based on what criteria?
Verbosity. Redundancy. Lack of orthogonality. Resemblance to English. The standard effectively mandates a particular storage strategy, with heavyweight tables that must provide certain CAP theorem guarantees instead of others. Rigid storage limitations: less in Postgres than in others, but why can’t I, say, nest schemas? Hell, why can’t I nest relations?
https://www.edgedb.com/blog/we-can-do-better-than-sql
https://www.edgedb.com/blog/we-can-do-better-than-sql
The whole industry, programming languages, infrastructure, everything would have developed differently if relations were a natural, pleasurable thing to use in any programming language. Like an Array, or a Hash.
Thee is nothing natural about either relations or arrays and hashes/dictionaries. Relations are pretty literal implementation of the basic set theory. Having a decent understanding of the basic set theory is a condition for understanding SQL. Now, we can discuss whether a language implementing a mathematical theory is "good" or "bad", whatever the meaning of "good" or "bad" in the given context. Historically, SQL is a good fit for the banking business and accounting and that is why it is still around.
Another misconception about SQL is treating it as a general purpose programming language. SQL is data description language, nothing more, nothing less. It doesn't need loops, arrays, hashes or subroutines, its principal purpose is to describe a subset of data. Without SQL you would have to read all the data and filter the unnecessary stuff yourself. Furthermore, part of SQL are so called "ACID requirements". Transaction can only see the data that was committed before the transaction has begun. Implementing ACID takes a lot of code, that's what MVCC is all about. However, that too has its origins in accounting. You cannot pay the money you don't have. And the last thing about SQL is transaction management. Without relational databases and SQL, you would need a proprietary transaction manager, just like MongoDB. And MongoDB has a complex proprietary transaction manager and is losing market share. So, to recapitulate:
• Declarative subset definition
• ACID consistency
• Transaction management
• Ideal fit for accounting.
That is why SQL is still around. And that is why we all live in a yellow subroutine (this reference is not for the millennials or younger)
You’re confusing SQL with the relational model. Datalog and Quel and Tutorial D and other database languages and systems can and did provide those features also.
pgsql-general by date: