Live data from Hacker News

We Can Do Better Than SQL

edgedb.com

311–320 of 466 posts

Re: We Can Do Better Than SQL

#311
post #291
post #84

It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should th…

> SQL is messy because describing the underlying data relationships are messy. No, the relational model is beautiful and consistent! SQL is messy because the syntax is not consistent and elegantly composable. It could have those properties and still present the same underlying data relationships. See Linq in C# as an example for how a more composable query syntax can expose the same data model. For example in Linq yo…

>For example in Linq you can chain arbitrary many select/join/where/group by in arbitrary order. In SQL you need nested subqueries to achieve the same which is a much more convoluted syntax.

WITH statements alleviate some of this issue by allowing you to write subqueries in any order.

Re: We Can Do Better Than SQL

#312
post #243
post #230

Earlier quoted context omitted.

> So, to summarize: I never actually heard a compelling general theory of good syntax. I started to think along these lines when I got serious about learning a foreign language. Humans appear to have some innate language ability that’s reflected, among other things, in commonalities between disparate languages. As far as I can tell, there’s been no serious effort to design a computer language to take advantage of thi…

The commonality you are referring to sounds like Chomsky's concept of Universal Grammar [1]. The object.method(args) "won" because it is a low barrier to entry from English to Programming indeed, but as you become more and more experienced and you shake off the imperative way of thinking in favour of declarative thinking functional languages becomes more expressive than imperative languages. They become better at man…

>The object.method(args) "won" because it is a low barrier to entry from English to Programming indeed

BASIC and C didn't have a concept of objects* , which didn't seem to hinder adoption at all. object.method() became popular when OOP languages became popular, and that was because IDEs offered better autocompletion with that syntax.

* We could emulate objects with C in some gnarly ways. Almost no one did at the time, excluding C-with-classes/C++.

Re: We Can Do Better Than SQL

#314
No.

Having worked with MongoDB for 5+ years now back to PostgreSQL, I do like SQL so much more than a custom query language. I would wish JSON would be better integrated in SQL, it kind of feels like an addon not the core. Otherwise SQL is a fine language.

Also I can leverage 20y of SQL.

Re: We Can Do Better Than SQL

#315
post #291

Earlier quoted context omitted.

> SQL is messy because describing the underlying data relationships are messy. No, the relational model is beautiful and consistent! SQL is messy because the syntax is not consistent and elegantly composable. It could have those properties and still present the same underlying data relationships. See Linq in C# as an example for how a more composable query syntax can expose the same data model. For example in Linq yo…

>For example in Linq you can chain arbitrary many select/join/where/group by in arbitrary order. In SQL you need nested subqueries to achieve the same which is a much more convoluted syntax. WITH statements alleviate some of this issue by allowing you to write subqueries in any order.

WITH (CTEs) make queries so much more readable and digestible. As a programmer who now does data and SQL, I latched on to these as soon as I found I could reduce repetition in a query with them.

Re: We Can Do Better Than SQL

#316
post #84

It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should th…

SQL is messy because describing the underlying data relationships are messy.

The article presents several examples where SQL's messiness cannot be plausibly attributed to underlying data relationship messiness.

Re: We Can Do Better Than SQL

#317
We could do a lot better than SQL. It's just that nearly every replacement falls into one of two traps:

A) Not being able to express relational semantics.

In general, every programming language replacing its predecessor allowed to express about the same semantics, even if it wasn't natural to the new language.

One can write imperative Java/C++ even if the language doesn't like it, and successful functional languages allow escape hatches for mutable objects.

The various NoSQL languages typically fail this hard.

B) Not offering enough of an improvement.

Minor improvement isn't worth the 'yet another query language' burden. EdgeQL doesn't fall into A, but it may fall into B.

NULL is an annoyance, but not big enough to justify another language. Throwing an exception instead is a very double-edged sword. The author needs to show far more improvement to justify a new language (I'd have liked to see more examples of composability for instance).

Re: We Can Do Better Than SQL

#318
post #181

Earlier quoted context omitted.

> SQL is messy because describing the underlying data relationships are messy. > SELECT extract(day from timestamp '2001-02-16 20:38:40'); SQL is messy because all the syntax was decided on before there was a community that really understood what good syntax is. The 'from' in that extract does nothing and I can't easily identify if extract is a function or some sort of crazy parsing construct - what are the arguments…

> It should be possible for an amateur to quickly write an SQL validator as a starting project ...why? SQL has been wildly paradigm-definingly useful for decades. It has driven hundreds of billions, perhaps trillions, of dollars of value. None of this hinges on the ability for an amateur to be able to write a validator for the language. It just seems like such a non-sequitur to me, such a strange thing to call out as…

I second this emotion SO HARD. Is sql weird? sure. But (IMO) the hard part implementing|using a sql database is _not_ the syntax, it's the storage, query planning, consistency. Don't like SQL? use linq or one of the bazillion DSL libraries that "compile" to sql. SQL databases are so unbelievably extremely useful, and the minor syntax quirks between different DBs are a minor issue compared to the huge amount of commonality that they share.

Also FWIW, I'm not sure that writing a sql validator _is_ all that hard. The grammars for any dialect are readily available and really not so hard to turn into an AST with any of your favorite tools (ANTLR, lex/yacc/bison, any of a million PEG parser generators). In many cases you don't even need to, we do static analysis of spark SQL using their own parser, for postgres can use the parser straight out of libpg.

I guess the OPs point is that if you can validate it easily, you can understand it. I'm certain I could write a lisp parser in 10 minutes, but I don't think that would mean I immediately understand all Clojure code (which is often pretty obtuse). You still need to learn all the underlying concepts and data structures.

Re: We Can Do Better Than SQL

#319

No. Having worked with MongoDB for 5+ years now back to PostgreSQL, I do like SQL so much more than a custom query language. I would wish JSON would be better integrated in SQL, it kind of feels like an addon not the core. Otherwise SQL is a fine language. Also I can leverage 20y of SQL.

EdgeDB is built on postgresql and has excellent JSON integration.

https://edgedb.com/docs/datamodel/scalars/json#type::std::js...

Re: We Can Do Better Than SQL

#320

Earlier quoted context omitted.

No, I'm with you and prefer SQL for many tasks. SQL got a bad rap in many ways due to security issues, databases in general, and "web-scale". SQL as a language within other languages is a nightmare from a security standpoint, and if language integrated query was more common across languages earlier on then this wouldn't have been an issue. Databases generally depend on normalization, but normalization comes with inte…

What is a good "web scale" solution?

Given that I’ve seen 25TB MySQL databases, RDBS scale up juuuuust fine. Just... have someone on hand who understands them if you’re going to go that high.
Post reply on HN