
We Can Do Better Than SQL (2019) - yamrzou
https://edgedb.com/blog/we-can-do-better-than-sql/
======
geebee
The last line here: "like any solution, SQL is facing increasing inadequacy in
the support of the new requirements, modes of use and user productivity. It is
time we do something about it."

I agree, but I'm not sure the solution is to broadly replace SQL with
something like EdgeQL. Graph Databases, BigTables, Document and Object
Databases, Large scale key-value lookup tables... there are all kinds of
solutions for problems that feel crammed into a SQL context. EdgeQL could be a
great one in some scenarios - for example, when you need to do a lot of
querying on arbitrary trees.

Another solution is to go as far as the sweet spot of SQL can take you, and
then switch over to a programming language (this is distinct from what is
_possible_ in SQL, the basis of many SQL programming interview questions)). I
suspect SQL compares less favorably in a lot of scenarios that require a pure,
single language solution. But may be we should be comparing SQL + Python with
EdgeQL + Python (or even SQL + EdgeQL + Python).

------
goto11
Any "improved SQL" could take some inspiration from .net's Linq. Some
conveniences in Linq compared to SQL:

\- From clause before the select clause. Makes it possible to use code
completion in the select clause.

\- Instead of the having clause, you just have a new where-clause after a
group-by, which operates on the groupings.

\- let-clauses where you can define expression which can then be re-used in
the following clauses.

\- composability, so you can have arbitrary many select/group/where/join/let
clauses in any order following the initial from-clause.

------
duiker101
I am no SQL expert, but I always found it a bit weird that selecting the
relationships is a relatively hard thing to do for a relational database.

What I mean is that relationships are at the core of the database, so they
should--IMHO--be easy. Instead, JOINS feel like some advanced feature that I
always see novices struggle with.

~~~
38911BBF
IMHO lots of teachers have an absolute horrible understanding of relational
databases and SQL. Myself included, until I started working at large financial
institutions and read every book by Joe Celko I could lay my hands on.

E.g. using NATURAL JOINs covers about 1/3 of the use cases where students or
apprentices are usually fiddling with INNER JOINs or joining relations using
WHERE TableA.ID = TableB.ID, and it's syntax is much simpler.

With a well thought out schema, I personally find that NATURAL JOINs covers
about 80% of my needs in that respect, and being unable to NATURAL JOIN tables
is beginning to indicate well, not a "code smell" but what I would call a
"schema smell".

I fully agree. Joining relations in a relational databases should absolutely
be simple - and it absolutely can be:

    
    
              SELECT col_x, col_y
                FROM TableA
        NATURAL JOIN TableB

~~~
duiker101
Thanks for your comment, I actually never heard of NATURAL JOIN, I will have
to play with it but it seems very interesting!

------
perl4ever
I am learning Power Query. It's the first Microsoft technology in quite a
while that's left a positive first impression.

I'm not particularly crazy about relearning how to do the things I would do in
SQL, differently. On the other hand, I feel like some of the straightforward
functional language features would be helpful to have in SQL.

I always felt like T-SQL and especially PL/SQL were terrible mistakes, but
that SQL was missing something.

Power Query didn't seem to have something like GROUPING SETS, but I was very
pleased when it seemed natural to roll my own as a function. SQL (at least the
dialects I'm used to) doesn't lend itself to that sort of thing.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=19871051](https://news.ycombinator.com/item?id=19871051)

