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

61–70 of 354 posts

Re: Against SQL

#61

Post by valenterry »

NavinF wrote: post #21

>The usual response to complaints about the lack of union types in sql is that you should use an id column that joins against multiple tables, one for each possible type. >create table json_value(id integer); >create table json_bool(id integer, value bool) >create table json_number(id integer, value double); No, the usual response is "Don't do that!" 99% of the time you either know the data types (so each JSON object…

But the world just works like that. There are unions everywhere. No matter how it's implemented under the hood, it should really be a first class concept in any language, including SQL.

Re: Against SQL

#62

Post by pdkl95 »

kinjba11 wrote: post #53
pdkl95 wrote: post #42

Earlier quoted context omitted.

They should use NATURAL JOIN if auto-selection of the join keys is that important. I wouldn't recommend relying on that type of automagic behavior because it is very brittle; adding a column to a table might accidentally break existing queries.

A natural join selects all matching names which is not the same as what the article is saying. The database already knows about foreign keys. Why do I have to say select * from A a join B b on b.Id = A.OtherId SQL IDEs will auto-suggest that "on b.Id = A.OtherId" because it's the foreign key and could be inferred. That's what you need 99% of the time.

> A natural join selects all matching names

Yes, which is why I called it "brittle". It can easily break if you aren't careful with column names. However, if someone really wanted (unwisely, in my opinion) to have the DB automatically handle their inner joins, they could use NATURAL JOIN. This would require being very careful with you column names, which is why I (strongly) recommend doing it the usual way with INNER JOIN.

> the foreign key and could be inferred

Only in simple cases. If there are multiple foreign keys referencing the same table, automagically inferring joins will probably do the wrong thing, just like NATURAL JOIN.

> IDEs will auto-suggest

The editor/IDE is where this type of automagic inference should be done! You have the opportunity to inspect the suggestion and fix it if necessary, instead of hoping the DB does the right thing at runtime.

Re: Against SQL

#63

Post by hugodrax157 »

bvrmn wrote: post #13

> fk_join(foo, 'bar_id', bar, 'quux_id', quux) This example has same amount of semantic entities as in SQL. Also there is USING. Also why author needs a strict modeling over json when one can model in native types? It's a very strange article.

It's also not obvious to me what has been gained from introducing a function which takes 5 unnamed arguments. Without looking at some separate (and therefore possibly wrong) documentation there's no way to guess what it's doing. Writing the SQL may take a bit longer but reading and understanding it is far easier.

Re: Against SQL

#64

Post by radiator »

roenxi wrote: post #38
dbsmith83 wrote: post #26

Earlier quoted context omitted.

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) ?

The first example, you can read it and speak it in English.

Re: Against SQL

#65

Post by Teafling »

einpoklum wrote: post #55
pjungwir wrote: post #10

It would be really cool if databases had an Option type. Then you could remove all the NULLs. Although you can mark a column as NOT NULL, that restriction doesn't "travel": it isn't present for function inputs/outputs, subquery results, etc. Adding it to the type system gives you a lot more mileage. And then joins could be option-aware: an inner join would have outputs matching the input types, but an outer join woul…

> It would be really cool if databases had an Option type. Then you could remove all the NULLs. A nullable T column _is_ an Option column, with NULL representing "Empty" or "No Value".

OP explains why this is not the same in all the other sentences of their comment

Re: Against SQL

#66

Post by zozbot234 »

roenxi wrote: post #38
dbsmith83 wrote: post #26

Earlier quoted context omitted.

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) ?

Most of the weirdness with SELECT could be fixed by switching the syntax to FROM ... WHERE ... [ GROUP BY ... HAVING ] ... SELECT ... ORDER BY.

Re: Against SQL

#67

Post by slx26 »

I think the problem of this essay is that it's overly technical: only those versed well enough in SQL will really care to read the whole thing, and if they are already at that level, either they accepted that "SQL will get the job done in the end", or they learned to live along it and now even kinda embrace it, and are happy to write about how the examples are very poor and dismiss the critique based on that, when the essay kinda explains it main point pretty well:

>> The core message [...] is that there is potentially a huge amount of value to be unlocked by replacing SQL

To me, a lot of people defends SQL saying that "perfect is the enemy of good" and that SQL simply works. Not the favourite of anyone, but everyone kinda accepts it.

And yeah, it's true. People use SQL because it's good enough, and trying to reinvent the wheel would take more work (individually speaking) than just dealing with SQL as it is right now. For large organizations where the effort could be justified, all your engineers already know SQL anyway, so it's not so great either.

But for something so relevant as relational databases, perfect is not the enemy of good. We do deserve better. We generally agree that SQL has many pitfalls, it's not great for any kind of user (for non-technical users, a visual programming language would work well here, more like what Airtable does, closing the bridge between spreadsheet and hardcore database, and for technical users, it does feel unwieldy and quirky). We should be more open to at least consider critiques and proposals for better. We might find out that people, from time to time, are making some good points.

Re: Against SQL

#68

Post by croes »

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.

The author explicitly said "the only solution" and that's plain wrong.

Re: Against SQL

#69

Post by xenomachina »

kinjba11 wrote: post #28
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…

> maybe they are asking a bit much from SQL But this article is thought provoking to say the least. It follows the courtroom logic of holding the defendant SQL on trial for as much as possible. And SQL is guilty of a lot of crimes. I do hope GraphQL and similar query languages become more prevalent and standardized, as it seems SQL could really use some stiffer competition.

Are you also talking about switching from a relational model to something graph-based, or is there some way one could use GraphQL with a relational database?

Re: Against SQL

#70

Post by roenxi »

mongol wrote: post #52
roenxi wrote: post #38

Earlier quoted context omitted.

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) ?

Shorter? No use of modifier keys? Just to name two. I think to do a meaningful comparison, more complex expressions should be used, that include joins, group by, order by etc...

There is pretty overwhelming evidence that using modifier keys is an advantage in this sort of thing. Pretty much every other language - possibly all of them - in common use make heavy use of modifier keys in describing what a computer should be doing. SQL is pretty much the dying breath of the attempts to do without them because the syntax is so bad in practice. Even configuration files typically make use of modifier keys.

Losing the explicit link between a function and its arguments is a big deal. Note that even the relational algebra model behind SQL doesn't try to make that sort of silly trade off.

Post reply on HN