Against SQL • Hacker News Board

Re: Against SQL

#251

Post by kybishop » Sat, Jul 10, 2021, 2:42 PM UTC

MetaWhirledPeas wrote: post #246

thrusong wrote: post #240

Earlier quoted context omitted.

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.

Among the various languages I use, why is SQL the only one that favors ALL CAPS EVERYTHING? When writing ad hoc queries I ignore that convention just to be ornery.

My honest take is that it's rare to name your tables and columns with all caps, whereas there are various cases where people do so with camelCase and snake_case.

In the end this makes spotting SQL-specific functions much clearer. I find it much easier to read SQL with this convention since my brain immediately knows when it's looking at context/project-specific data or a FUNCTION.

Re: Against SQL

#252

Post by ngrilly » Sat, Jul 10, 2021, 2:44 PM UTC

quietbritishjim wrote: post #162

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

I agree that a programmatic API semantically equivalent to SQL – for example like the JSON-based MongoDB API you mentioned – would go a long way making things easier for application developers and removing the need for ORMs (which I consistently avoid).

F1, Google's SQL database, uses Protocol Buffer in an interesting way: https://storage.googleapis.com/pub-tools-public-publication-...

Re: Against SQL

#253

Post by muixoozie » Sat, Jul 10, 2021, 2:47 PM UTC

BeFlatXIII wrote: post #158

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…

I find the fact that others cannot borrow my computer to be a major plus of using non-QWERTY layouts. Your point about keyboard shortcuts is spot-on: forget hjkl navigation in vim if you’re not QWERTY.

The point about hjkl is the biggest deal here. Everything else has been non-issues me.

Interesting to note that Emacs standard key-bindings don't have the issue (from what I heard). However, I use evil in Emacs and Colemak-dhm layout and I decided to rebind all evil / vim keys. This fixes the position issues, mnemonic issues, and gave me the opportunity to improve on a bunch things over the defaults in QWERTY.

I very rarely type on anyone else's computer. Usually when I do it's my wife's computer (maybe 5 time's a year). I have a small 40% keyboard with QMK firmware so it's easy to transport and everything I need is flashed into the firmware. No need for configuration of the keyboard layout on their OS.

Re: Against SQL

#254

Post by spicybright » Sat, Jul 10, 2021, 2:48 PM UTC

koheripbal wrote: post #239

spicybright wrote: post #182

Earlier quoted context omitted.

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.

Hense, so far they all seem to suck.

While I agree with you, it's too bad you can't create macros over common patterns. Not sure about you but I copy and paste a ton for this.

Really, I'd just want a coffee script, or moon script (https://moonscript.org/) where you have the idea for a query in your head, and know what the constructs will ultimately generate.

Re: Against SQL

#255

Post by goto11 » Sat, Jul 10, 2021, 2:49 PM UTC

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.

True. (You can in some databases using check constraints, but it is not necessarily simple) The solution is to improve the constraint model to make it much simpler to define such constraints. For example it is trivial (in most databases) to add primary key and foreign key constraints, but more complex constraints are difficult or impossible.

I think the desire for tagged unions are really an XY problem, just like the desire for array types and other composite types. The relation type itself is powerful enough. But the desire for such features show that certain patterns are too complex and un-intuitive to apply in SQL.

Re: Against SQL

#256

Post by dominotw » Sat, Jul 10, 2021, 2:50 PM UTC

KingOfCoders wrote: post #72

We're currently moving into a different direction, removing Spark Code to move most of the stuff into BigQuery SQL (which can use structs, one of the points of the article), because it's easier for Data (Engineers|Analysts|Scientists) to write SQL than e.g. Scala.

Same here. Lots of places are doing this, afaik.

shopify from pyspark -> sql

https://shopify.engineering/build-production-grade-workflow-...

Re: Against SQL

#257

Post by jackbravo » Sat, Jul 10, 2021, 2:55 PM UTC

Here in hacker news it was posted this article about the story of SQL biggest rival, QUEL, which is pretty related: https://www.holistics.io/blog/quel-vs-sql/?

It is not that we didn't try to replace it, but just as other comments have said, SQL was good enough, and already has the biggest mind share.

Re: Against SQL

#258

Post by ako » Sat, Jul 10, 2021, 2:59 PM UTC

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.

Agree, probably because it's not what people are looking for. Most devs complain they don't have enough control over how a query is executed, they want to be closer to the actual storage, as they think they can do a better job deciding how data should be retrieved than the database engine.

Adding another abstraction layer on top would only increase this frustration, as they'd have even less control.

Re: Against SQL

#259

Post by jmull » Sat, Jul 10, 2021, 2:59 PM UTC

So what?

Complaining about SQL is the easy part. Actually, it's the first skill most new SQL developers truly master.

I'm waiting for the viable alternative. There are a lot (a LOT) of solutions that handle some cases, but inevitably you need to get into the SQL anyway because that's the DBMS' native API (and now you also need to fight your way through the abstraction, oh and since there are a LOT of solutions a different one is used every chance someone gets, so you need to relearn how to fight through the abstraction all the time).

I doubt it's going to change. There's actually no significant reason. SQL (actually, the set of mutually incompatible SQL variants) is thoroughly entrenched and a small problem... that is, it's rarely the dominant reason a project/product succeeds or fails, or takes too long, or becomes unmaintainable, etc.

Re: Against SQL

#260

Post by asavinov » Sat, Jul 10, 2021, 3:02 PM UTC

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…

> I think SQL is irritatingly non-composable, many operations require gymnastics to express

One approach to radically simplify operations with data is to use mathematical functions (in addition to mathematical sets) which is implemented in Prosto data processing toolkit [0] and (new) Column-SQL [1].

[0] https://github.com/asavinov/prosto Prosto is a data processing toolkit - an alternative to map-reduce and join-groupby

[1] https://prosto.readthedocs.io/en/latest/text/column-sql.html Column-SQL (work in progress)