Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Against SQL

scattered-thoughts.net

Post reply on HN
Print view View original

31–40 of 354 posts

Re: Against SQL

#31

Post by pjmlp »

progre wrote: post #14

I do love SQL and at least where I live (MS SQL Server) it can be made to run amazingly fast if you take some care with your queries and indexes. It's not portable though: as far as I know not a single one of the big sql vendors follows the standards 100% and more importantly, spending some time with one vendor will give you some habits that are sure to not work as well with another (cursor constructs are generally a…

Yeah, however it is kind of strange to single out SQL, when we have examples like a very famous kernel that can only make use of specific compiler, or Web APIs that are only implemented by a specific browser.

Re: Against SQL

#32

Post by SPBS »

SQL is a pretty warty implementation of relational databases (with non-composability being its primary sin IMO), but we're stuck with it at this point. A new querying DSL that fixes all of SQL's flaws is only half the story, getting enough programmers on the planet to buy into it is another half. To do that you'd need this new piece of software to at least be as fast and as battle tested as existing SQL databases. Even the new generation of massively-scalable relational databases stick with some form of SQL instead of inventing a new DSL because of the sheer momentum behind this sorry syntax.

Re: Against SQL

#34

Post by benjiweber »

> By far the most common case for joins is following foreign keys. SQL has no special syntax for this

You can use NATURAL JOIN

select * from foo natural join bar

Works as long as the keys are named the same. However, a lot of people have a habit of naming keys differently in the two tables.

Re: Against SQL

#35

Post by pjmlp »

kinjba11 wrote: post #8
croes wrote: post #2

>what if we want to return the salary too? >the only solution is to change half of the lines in the query How about adding a second subquery for the salary.

It is a toy example. Perhaps imagine a more realistic subquery that is much longer. Are you going to duplicate a 50 line subquery to get the salary when all you want is one more value ? No, you'd probably want to restructure the query with a join or CTE instead. To the author's point, a large change relative to the gain.

No, I will write a SQL function for the subquery and call it from the main query.

Re: Against SQL

#36

Post by erezsh »

I share the author's point of view, which led me to start a new relational programming language that compiles to SQL. It's a way to build on existing databases, like postgres or mysql, with all of their advantages, but improve on many of SQL's limitations.

If that sounds interesting, you can find it here: https://github.com/erezsh/Preql

Re: Against SQL

#37

Post by pjmlp »

kinjba11 wrote: post #11
gerbler wrote: post #4

Earlier quoted context omitted.

This example seemed wrong to me as well. You can have a subquery, or CTE that returns as many fields as you want and can join on the manager key

An additional subquery and a CTE are both restructuring the query significantly, which is the author's point.

Well if he is insisting in doing the SQL version of writing everything inside a lambda without modularizing the code, then yeah that is bound to happen.

Re: Against SQL

#38

Post by roenxi »

dbsmith83 wrote: post #26
roenxi wrote: post #20

One of the elephants in the room with SQL is that it is one of a small number of popular languages that doesn't use function(arg, arg, arg) It is strange that "SELECT a, b, c FROM schema.table" keeps any aura of respectability. That is legitimately outdated syntax, people don't write languages that way any more. It was a 70s era experiment and what was learned from that experiment is that the style has no upside and…

Comparing SQL to those other languages doesn't really make sense. Their purpose is different. For what SQL does, the syntax makes a lot of sense because it is a completely different paradigm. I think it's dismissive to refer to SQL as merely a 70s experiment. It is used so widely today still

What advantages do you think

    SELECT a, b, c FROM d
has over even a trivial modernisation like, say,

    table(d) |> select(a, b, c)

?

Re: Against SQL

#39

Post by kinjba11 »

ltbarcly3 wrote: post #7

Lots of the examples here are yhe author writing very poor, non idiomatic SQL and then criticizing it. I could write a point by point rebuttal but I'll just pick one point, compressibility: VIEWs.

I've been around quite a bit of SQL, and views are great. But they're not exactly as easy as assigning to a variable. If I followed your logic per compressibility I'd have to be creating views - permanent global objects - for almost every query I write. Do you create views every time you need to write some ad-hoc SQL?

Re: Against SQL

#40

Post by rawoke083600 »

I've been thinking about this problem a lot, CRUDs, GraphQL,ORMs, Models etc. Mostly in the "CRUD-Like" environment. I have been thinking about a "client side SQL impl".

In most CRUD's we currently have on the backend layers and layers of software with ORMS, frameworks etc, and it all boils down to "Writing/Generating the correct(good-enough) SQL"

We now have added stuff like GraphQL, which if you squint hard enough (ok very hard) can be seen as being a SQL alternative(Language to get the actual data).

Maybe SQL + "GraphQL-Like" Layers should "evolve" into ONE common "data scripting language" ?

Maybe we have something like "ClientSide-SQL" - which can be a subset of ServerSide-SQL ?

We need the "TypeScript" of "data-querying" which can be run on the server,client, moon and my device, where one can also only define any "Types" ONCE.

Anywhoo - I think there is still a lot to be done, researched and discovered in this section of CS :)

Post reply on HN