On Sep 14, 2021, 12:51 -0700, Mladen Gogala <gogala.mla...@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 > > > > 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.
