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

161–170 of 354 posts

Re: Against SQL

#161

Post by trollied »

ako wrote: post #131
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…

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.

I agree. I’ve seen people bashing SQL ever since I started using it 25 years ago, but I’ve yet to see an attempt to replace or supersede it succeed.

Many of these blog articles seem to be written by devs that have only really experienced the user-facing application side of things, and really don’t realise the sheer number of financial, analytic & business systems, that keep the world spinning round, that are all happily buzzing away using SQL.

Moaning about JSON manipulation in SQL is madness. A client should use appropriate joins to get the data from the database & then do the transformation. Storing JSON when you actually need to perform operations on said data makes 0 sense. It’s a huge overhead, an utter nightmare to index etc.

Re: Against SQL

#162

Post by quietbritishjim »

ngrilly wrote: post #143

A more pragmatic view in that article: https://blog.nelhage.com/post/some-opinionated-sql-takes/

Thanks, that's a great article. It has just the right balance of some interesting things I didn't know with enough things I agree with that I believe it!

I agree with the desire for a data-based language, rather than text-based one as SQL is. A classic example of this is MongoDB: you can add a new filter by just adding a new entry to a dict in Python or object in JS etc. I think 99% of the reason MongoDB was successful, at least in the early days, was because of its data based API. (Polite request to all: please don't reply to this comment with pros/cons of MongoDB except it's query language.)

I especially agree with the point about having to trick query planners into using the indices you wrote. I get that sometimes it's nice to let the database engine cleverly choose the best strategy (dynamically building queries with a data-based API would be a case in point). But in other situations you'll have carefully designed the tables and indices around one or more specific queries, and then it's frustrating not being able to directly express that design in the code.

I don't have any experience with live migration of production databases (thankfully!) so that was interesting, especially the conclusion that MySQL is best for this, which I didn't expect. The idea of separating out the type system into lower-level "storage types" and higher-level "semantic types" was also food for thought.

Re: Against SQL

#163

Post by sam_lowry_ »

james_woods wrote: post #41

SQL was not made for programmers alone. It has been invented also for not so technical people so that verboseness and overhead is part of the deal. > When Ray and I were designing Sequel in 1974, we thought that the predominant use of the language would be for ad-hoc queries by planners and other professionals whose domain of expertise was not primarily data- base management. We wanted the language to be simple enoug…

This is a recurring theme. I was once amazed to learn that ClearCase was made for lawyers to use. The name makes suddenly a lot of sense!

Re: Against SQL

#164

Post by Aeolun »

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…

I don’t know. If someone gives me an interface like Prisma, and the backing database does not use SQL, but is otherwise the same, that just removes one needless translation step, and I wouldn’t have to do anything.

Re: Against SQL

#165

Post by mickael-kerjean »

pjmlp wrote: post #29

> Why did SQL have to add it to the language spec? Most likely because there isn't cargo for SQL, everyone has to make do with a default install offers, and most big boys databases offer FFI to Java, .NET and C. > This works for data modelling (although it's still clunky because you must try joins against each of the tables at every use site rather than just ask the value which table it refers to) Only if one never l…

After years of doing that same technique, in my new job, people would write:

   SELECT foo.id, quux.value
   FROM foo, quux, bar
   WHERE foo.bar_id = bar.id AND bar.quux_id = quux.id
I couldn't find anyone telling me the difference between those 2 ways to write a query, do someone know more about this?

Re: Against SQL

#166

Post by Aeolun »

danbruc wrote: post #75

I wonder how much of the limitation are necessary in order for the query optimizer to have any chance at finding a good execution plan. As you add more and more abstractions and more and more general computations in the middle of your queries, it will probably become harder and harder for the query optimizer to understand what you are actually trying to do and figure out how to do it efficiently. Are you not running…

> otherwise you might get in the way of efficient query execution

Maybe? But I kind of feel that the query optimizer often gets in the way of efficient query execution.

There’s so much stuff that’s semantically the same, but if you shuffle some strings around, the query is suddenly 10 times faster.

Re: Against SQL

#167

Post by zabzonk »

papito wrote: post #156
zabzonk wrote: post #137

Earlier quoted context omitted.

> We wanted the language to be simple enough that ordinary people could ‘‘walk up and use it’’ with a minimum of training. In that case it has been an abject failure. I have been using SQL since the mid 1980s (so pretty much since the start of its widespread adoption) and I have never met "ordinary people" (by which I assume intelligent business-oriented professionals) who could (or wanted to) cope with it. I like it…

I don't think this is disputed that the original goal of SQL was a flop. The designers grossly underestimated the technical chops of a layman. However, I would argue that us tech people did benefit from that original goal of simplicity. I mean, SELECT first, last FROM employees WHERE id = 10 is not too bad at all. Kind of elegant, no? If SQL was designed "by engineers for engineers", you would be using esoteric Git c…

> Kind of elegant, no?

Oh, I agree, which I said "I like it", and compared to things like CODASYL it was and is shining sanity.

Re: Against SQL

#168

Post by [deleted] »

smitty1e wrote: post #157

> First, while SQL allows user-defined types, it doesn't have any concept of a union type. Isn't a union type essentially a de-normalized field? This seems like attacking arithmetic operators for their lousy character string support. Weren't XML databases (briefly) a (marketing) thing some decades back? One idea might be to have everyone integrate jq[1] into their database engines. My understanding is that one can ma…

[deleted]

Re: Against SQL

#170

Post by Aeolun »

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.

I do not understand the comparison between SQL and GraphQL. As far as I can see they’re not close to the same. And GraphQL is also missing a bunch of really necessary things.
Post reply on HN