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

231–240 of 354 posts

Re: Against SQL

#231

Post by neuronic »

blacktriangle wrote: post #227
ako wrote: post #131

Earlier quoted context omitted.

There's a lot of talk about what is wrong with SQL, but i haven't seen something yet that is actually better than SQL for most use cases. Stop fighting SQL so much, and just focus on bringing a better solution. If potential users see it has significant benefits they'll start using it.

In theory datalog is better than SQL. However the reality is that we have millions of programmer-hours invested in making SQL perform well where datalog has no where near this effort. I think that's why NoSQL is where the gains are being made. You can't magically improve things with a query language without putting the effort into performance, but you can get huge gains by changing your assumptions about how data is…

Can you? For every article hating SQL there is one for hating NoSQL: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...

Re: Against SQL

#232

Post by goodpoint »

endymi0n wrote: post #99
slx26 wrote: post #67

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 th…

SQL is exactly like the QWERTY layout: A first quickshot with little design thoughts and unfixable architectural issues that‘s so widespread that everyone is used to it by now. Trying to change to the Dvorak layout taught me a lot about enacting change on such a grand scale. After a lot of hassle switching machines and OSes, typing on other user‘s computers, them typing on mine and general headaches among internation…

> typing on other user‘s computers

Off-topic, but changing layouts is easy. Also, using other people's keyboards is not the best for hygiene even before covid.

Re: Against SQL

#233

Post by [deleted] »

endymi0n wrote: post #99
slx26 wrote: post #67

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 th…

SQL is exactly like the QWERTY layout: A first quickshot with little design thoughts and unfixable architectural issues that‘s so widespread that everyone is used to it by now. Trying to change to the Dvorak layout taught me a lot about enacting change on such a grand scale. After a lot of hassle switching machines and OSes, typing on other user‘s computers, them typing on mine and general headaches among internation…

[deleted]

Re: Against SQL

#234

Post by goto11 »

laszlokorte wrote: post #174
goto11 wrote: post #102

Earlier quoted context omitted.

You can already do that by having circle and rectangle relations. Union types dos not give you any additional power compared to relations. Your proposal might be more convenient though than creating multiple relations, so we should look into making it just as convenient to create the necessary relations to express this. So lets say your syntax proposal creates multiple relations under the hood - then I'm all aboard!…

But if I have a circle relation and a triangle relation, how do I create a foreign key for the favourite_shape column in my user relation?

You would have the foreign key in the circle/triangle relations pointing to favourite_shape rather than the other way around.

Re: Against SQL

#235

Post by ledauphin »

DeusExMachina wrote: post #104
endymi0n wrote: post #99

Earlier quoted context omitted.

SQL is exactly like the QWERTY layout: A first quickshot with little design thoughts and unfixable architectural issues that‘s so widespread that everyone is used to it by now. Trying to change to the Dvorak layout taught me a lot about enacting change on such a grand scale. After a lot of hassle switching machines and OSes, typing on other user‘s computers, them typing on mine and general headaches among internation…

While I agree with your point, I wonder why that does not seem to be the case with programming languages. For example, in iOS development (and, more in general, on Apple platforms), there has been a huge shift from Objective-C to Swift. The same arguments should apply there. Swift is much better, but Objective-C got the work done, and many codebases were written in it, especially at Apple. And yet, the whole communit…

Ironically, at least in the case of ObjectiveC->Swift, the answer is almost certainly "because those languages compose with each other reasonably well". I say ironically because I believe most of this article boils down to how uncomposable SQL is.

I think the same can be said of Java -> Kotlin, C -> Python (I know, I know), and lots of other medium-to-large scale language migrations over the past several decades. When people move to a new language, it's because there's strong interoperability with what came before that everyone would like to quit using but can't because they have too much invested in it.

This suggests to me that anything that wants to beat SQL will in fact have to compose with it - probably partly by generating it, but also by having a fairly solid "drop down to SQL" story. In other words, a language that, at least on the read-side, can somehow take two separate SQL queries and automatically rewrite them as subparts of a different SQL query. It might not be fast, but it needs to work, because you're going to want to reuse that work on that one gnarly query you did that gets all the important business metrics, and you also are going to want your results to be free of consistency issues.

Re: Against SQL

#236

Post by ampdepolymerase »

barrkel wrote: post #121
slx26 wrote: post #67

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 th…

I think I'm experienced enough to understand the article, and I agree. I've written multiple optimizing SQL generators (altering generated SQL to access better plans), and rewritten hundreds of queries for better performance, which involves trying many semantically identical rewrites of the same query. I agree with Jamie. I think SQL is irritatingly non-composable, many operations require gymnastics to express, and I…

Have you tried Logica?

https://logica.dev/

Re: Against SQL

#237

Post by gfody »

wibblewobble123 wrote: post #197
goto11 wrote: post #97

Earlier quoted context omitted.

SQL already have first class support for union types in the form of relations. Adding union-type columns would actually be second class compare to this. You would have to add special-case operators and it wouldn't give you more power compared to just using relations. That said, I'm not averse to the idea if someone can provide a realistic use case. The JSON example in the article is misguided though - you should not…

Relations don’t provide sum types in a first-class way. If you want a list of employees each of which have different roles, and depending on the role you have different fields guaranteed to be available (not null), this is not possible to express directly in SQL. You can express this with sum types in ML, Haskell or Rust. In SQL you would have to split it out into separate relations, like: create table employee(id it…

>You can express a foreign key constraint that these tables must link to an employee, but not the other way around. You can’t guarantee in the limited type system of SQL that every employee row has a corresponding employee_X table, and exactly one, not more.

in this case instead of an employee table you would have an employee view that’s the union of the separate tables - engines vary dramatically in what sort of constraints they’ll enforce on the view now but the relational model is fine

Re: Against SQL

#238

Post by barrkel »

spicybright wrote: post #182
barrkel wrote: post #121

Earlier quoted context omitted.

I think I'm experienced enough to understand the article, and I agree. I've written multiple optimizing SQL generators (altering generated SQL to access better plans), and rewritten hundreds of queries for better performance, which involves trying many semantically identical rewrites of the same query. I agree with Jamie. I think SQL is irritatingly non-composable, many operations require gymnastics to express, and I…

What is your opinion on abstractions on top of SQL queries? On paper, a more expressive language that spits out SQL queries sounds great, but I've never seen a single one not become a pain in the ass to use.

Something as fully expressive as SQL is hard to design well. I think jOOQ is one of the best, but it relies on code generation to get good typing.

The context for my generators was querying over data whose schema was customer defined. I wrote two generators in Ruby and one in Java. They were designed to take advantage of quirks and performance characteristics of MySQL when doing arbitrary ad-hoc sorts and filters, and the optimization was mostly about delaying joins if they weren't necessary for the predicates, and creating an inside out nest of subtable queries to control the execution plan.

Doing this without a generator of some kind is impossible - the columns are dynamic - and then you leave a lot of performance on the table if you don't tune.

Re: Against SQL

#239

Post by koheripbal »

spicybright wrote: post #182
barrkel wrote: post #121

Earlier quoted context omitted.

I think I'm experienced enough to understand the article, and I agree. I've written multiple optimizing SQL generators (altering generated SQL to access better plans), and rewritten hundreds of queries for better performance, which involves trying many semantically identical rewrites of the same query. I agree with Jamie. I think SQL is irritatingly non-composable, many operations require gymnastics to express, and I…

What is your opinion on abstractions on top of SQL queries? On paper, a more expressive language that spits out SQL queries sounds great, but I've never seen a single one not become a pain in the ass to use.

I never understood the point of this. SQL is easy to learn and usually easy to write, and usually easy to performance tune.

I find that if my query is getting overly complex, that some of the logic is often better suited in the app layer.

At best, you are spending time learning something niche with little upside. At worst, you are introducing buggy bad performing complexity.

Re: Against SQL

#240

Post by thrusong »

slx26 wrote: post #67

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 th…

I completely agree with you. Is SQL perfect? No. Have I accepted and embraced it? Yes, because it'll get the job done.

I also happen to really dislike how the author hasn't capitalized the syntax like SELECT FROM WHERE or CREATE TABLE which, to me, poorly affects the legibility and therefore makes me less interested in reading the argument overall.

Post reply on HN