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

201–210 of 354 posts

Re: Against SQL

#201

Post by dan-robertson »

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 think the fact that many people were willing to try switching to mongodb despite the fact that it doesn’t use sql and had quite poor semantics should suggest that there would be some way for a better relational database query language (and engine) to catch on.

On the other hand, the fact that many new time series databases (and other engines, including Materialize which the author of the article worked on) wanted sql (or fake sql-like languages when they couldn’t manage sql) suggests that not being sql can be a big hindrance.

Re: Against SQL

#202

Post by Kinrany »

vbsteven wrote: post #119
b33j0r wrote: post #77

Earlier quoted context omitted.

To me, SQL looks like something I should be using 79-char punchcards for. Scalable databases are just so difficult that we’re still driving a ‘64 IMPALA Most of this opinion comes from “SQL” being vendor-specific. Is JSON vendor-specific? Is anything else, that we actually use by choice? Mad at you too, Graph DBs, for sending us on another snipe hunt by adding vendor-imposed innovations, because it makes the enterpri…

> Most of this opinion comes from “SQL” being vendor-specific. Is JSON vendor-specific? Is anything else, that we actually use by choice? Two things that come to mind are Markdown with all its flavors and Regex with multiple engines. edit: and to a lesser extent maybe C/C++ compilers and JS engines. edit2: also JVM, Python and Ruby runtimes But both edits describe technologies with an official spec and slightly diffe…

CommonMark and ECMAScript+bundlers exist, so it's very easy to write Markdown and JS against a standard and be interpreter-agnostic.

SQL standard only covers the basics and is only useful to humans, not machines.

Re: Against SQL

#203

Post by erezsh »

dvdkon wrote: post #194
erezsh wrote: post #183

Earlier quoted context omitted.

I don't have a lot of experience writing Lisp-y code, so perhaps I'm speaking from ignorance, but I think there is a reason that syntax never gained huge traction. Imho a syntax that's concise and expressive is important for effective coding. Having operators for the most common operations is just a small complication that yields a big reward. Having said that, the amount of keywords and operators that you see in Pre…

Thanks for the reply. I'm happy that others are also tackling the problem of a better query language. My approach isn't actually a full-on Lisp with parentheses and all, rather it's based on a single compound data structure (like Lisp's cons cell, but more like Lua tables). I call it an "arg-tuple", and it's basically a function's arguments in Python, but as a data type (which allows nesting). Add in a simple functio…

Python has a data structure like this called NamedTuple.

I also noticed it's popping up everywhere, in this case sql rows (kind of). Conceptually I like the idea of using it as the mechanism for function arguments, but I didn't want the syntax to be too confusing for beginners.

Although yours seems a little bit different, because different fields can have the same name.

Just for the heck of it, here's how your second example would look in preql:

    (stops
    { lat, lon => }
    { lat => lon: min(lon) } 
    { lon }    // not necessary. just drops the lat column
    )

Re: Against SQL

#204

Post by WillDaSilva »

thinkr42 wrote: post #200

Though verbose and somewhat strange at times, one thing I love about SQL is that the query statements read like a set definition from set theory. That declarative nature is pretty powerful IMO, sure there are hiccups but it is a different way of thinking.

The (mostly) declarative nature of SQL is not something the post is criticizing. You could have a good declarative language for relational database that doesn't suffer from the things the post criticizes.

Re: Against SQL

#205

Post by xarope »

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 always thought that was what hadoop had in mind with HDFS, i.e. move the storage and query engines closer in terms of spatial and temporal locality, albeit only if you partitioned/clustered properly.

Speaking of which, what has happened to hadopp and HDFS? Used to be flavor of the month about 10 years ago, but now I hardly ever hear people talk about it.

Re: Against SQL

#206

Post by justsomeuser »

aenis wrote: post #120
qPM9l3XJrF wrote: post #49

Earlier quoted context omitted.

>spending some time with one vendor will give you some habits that are sure to not work as well with another It seems like having multiple vendors is only valuable if their products are to some degree differentiated, no?

For me the opposite is true. The value of multiple vendors with a similar product is that it drives prices down and liberates me from a lock in. I genrally avoid managed services that are not available from all three major cloud providers, and put abstractions between my suff and their so I can move my workloads around. As to SQL. Its a weird feeling to read all that; I've spent 15 years working with very large relat…

What do you use for your KV storage?

Re: Against SQL

#207

Post by nesarkvechnep »

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.

Elixir's Ecto.

Re: Against SQL

#209

Post by ebingdom »

valenterry wrote: post #179
ebingdom wrote: post #123

Earlier quoted context omitted.

The author uses the term "union", but unfortunately they picked the one wrong term against a long list of correct alternatives: sum type, tagged union, discriminated union, coproduct, disjoint union, variant, algebraic data type, ... "Union" does not imply disjointness (which is the source of many problems), whereas all those other terms do.

Correct, I just continued to use the term of OP. Sum types r coproducts are what I mean.

By the "author", I meant the author of the article. I figured you were just being consistent with them.

Re: Against SQL

#210

Post by JoelJacobson »

I suggest using the fact foreign keys are constraints with unique names, and using these names to explicitly specify what column(s) to join between the two foreign key tables.

In PostgreSQL [2], foreign key contraint names only need to be unique per table, which allows using the foreign table "as is" as the constraint name, which allows for nice short names. In other databases, the names will just need to be a little longer.

Given this schema:

  CREATE TABLE baz (
  id integer NOT NULL,
  PRIMARY KEY (id)
  );
  
  CREATE TABLE bar (
  id integer NOT NULL,
  baz_id integer,
  PRIMARY KEY (id),
  CONSTRAINT baz FOREIGN KEY (baz_id) REFERENCES baz
  );
  
  CREATE TABLE foo (
  id integer NOT NULL,
  bar_id integer,
  PRIMARY KEY (id),
  CONSTRAINT bar FOREIGN KEY (bar_id) REFERENCES bar
  );
We could write a normal SQL query like this:

  SELECT
    bar.id AS bar_id,
    baz.id AS baz_id
  FROM foo
  JOIN bar ON bar.id = foo.bar_id
  LEFT JOIN baz ON baz.id = bar.baz_id
  WHERE foo.id = 123
I suggest adding a new binary operator, allowed anywhere where a table name is expected, taking the table alias to join from as left operand, and the name of the foreign kery contraint to follow as the right operand.

Perhaps "->" could be used for this purpose, since it's currently not used by the SQL spec in the FROM clause.

This would allow rewriting the above query into this:

  SELECT
    bar.id AS bar_id,
    baz.id AS baz_id
  FROM foo
  JOIN foo->bar
  LEFT JOIN bar->baz
  WHERE foo.id = 123
Where e.g. "foo->bar" means:

  follow the foreign key constraint named "bar" on the table/alias "foo"
If the same join type is desired for multiple joins, another idea is to allow chaining the operator:

  SELECT
    bar.id AS bar_id,
    baz.id AS baz_id
  FROM foo
  LEFT JOIN foo->bar->baz
  WHERE foo.id = 123
Which would cause both joins to be left joins.

  SELECT
    bar.id AS bar_id,
    baz.id AS baz_id
  FROM foo
  LEFT JOIN foo->bar->baz
  WHERE foo.id = 123
[1] https://scattered-thoughts.net/writing/against-sql/

[2] https://www.postgresql.org/

Post reply on HN