We Can Do Better Than SQL • Hacker News Board

Re: We Can Do Better Than SQL

#201

Post by roenxi » Tue, Aug 11, 2020, 9:47 AM UTC

ideamotor wrote: post #195

roenxi wrote: 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…

Please use pivot_wider and pivot_longer instead of gather and spread. The true horror, even admitted by the the dplyr team ...

Oh, they're new. Great. Thanks for the tip.

Re: We Can Do Better Than SQL

#202

Post by dsego » Tue, Aug 11, 2020, 9:49 AM UTC

Flimm wrote: post #194

Yes, SQL has flaws, and the article forgot to mention one of them: you need to build a string to build an SQL query, rather than a more structured object, leading to flaws like SQL injection vulnerabilities, and difficulties adjusting the query. Let's say you're building a CRUD app with search and filtering capabilities. Unless you are using an ORM (which has problems of its own), you might be tempted to build the SQ…

> the article forgot to mention one of them: you need to build a string to build an SQL query

IMO this is in the article mentioned as 'poor system cohesion':

> poor system cohesion — SQL does not integrate well enough with application languages and protocols

----

> I don't think a new query language solves this problem.

LINQ ?

Re: We Can Do Better Than SQL

#203

Post by marmada » Tue, Aug 11, 2020, 9:49 AM UTC

I see a lot of Stockholm syndrome in this thread / maybe low expectations.

Many people are saying SQL isn't that hard to learn but as someone who is new to SQL, I disagree.

It takes a max of 15 minutes to understand basic JavaScript/Go/Python primitives and write a program. SQL on the other hand seems much more complex. I might as well be reading Haskell or Lisp. At least those languages are consistent.

SQL does not feel like a language where I can learn a few primitives really quickly and compose them together.

Re: We Can Do Better Than SQL

#204

Post by rplst8 » Tue, Aug 11, 2020, 9:52 AM UTC

quickthrower2 wrote: post #120

tqi wrote: 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…

I was hoping for something more left field myself. If SQL is based on tables, what about a QL based on relations only. Columns of data that are related, the "TABLE" implementation detail doesn't need to factor into it.

> If SQL is based on tables, what about a QL based on relations only.

Try Sparql.

Re: We Can Do Better Than SQL

#205

Post by Flimm » Tue, Aug 11, 2020, 9:54 AM UTC

maweki wrote: post #197

Flimm wrote: post #194

Yes, SQL has flaws, and the article forgot to mention one of them: you need to build a string to build an SQL query, rather than a more structured object, leading to flaws like SQL injection vulnerabilities, and difficulties adjusting the query. Let's say you're building a CRUD app with search and filtering capabilities. Unless you are using an ORM (which has problems of its own), you might be tempted to build the SQ…

This problem would arise with every DSL. And it has been solved by using embedded DSLs. jOOQ or SQLAlchemy look like SQL (and you don't even have to squint your eyes very much) and solve the problems you mention.

jOOQ and SQLAlchemy are libraries for Java and Python respectively. You can't take your knowledge of those libraries and use them in a different programming language. And you still need to know SQL well in order to do any debugging, because the database is still receiving an SQL query string.

What I am wishing for is for the language to be more like JSON, something that matches closely to commonly found structures in programming languanges (like lists, objects, numbers, strings and booleans), and that the database can support natively.

Re: We Can Do Better Than SQL

#206

Post by bryanrasmussen » Tue, Aug 11, 2020, 9:55 AM UTC

tqi wrote: 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…

>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...

Obligatory XKCD https://xkcd.com/927/

Re: We Can Do Better Than SQL

#207

Post by YohAsakura » Tue, Aug 11, 2020, 9:59 AM UTC

Some comments here, in my opinion, are missing the point. Saying "SQL is good enough, no need for EdgeQL" is like saying "C/C++/Java/... is good enough, no need for Rust/Kotlin/...".

EdgeQL is an explicit attempt to make not a new version of SQL, but a new language. It's about evolution, which is, again, explicitly noted. Saying "evolution is not needed" or "I don't want/need evolution" is strange to me. At the same time, giving constructive feedback is useful, as always.

Re: We Can Do Better Than SQL

#208

Post by fho » Tue, Aug 11, 2020, 9:59 AM UTC

I might be ignorant here ... but why not have disc backed datastructures and have some sort of ECS style interface that is like "normal" programming?

In pseudocode:

    newtype id = int
    names = dict()
    balances = dict()
    credit_scores = dict()
    
    function broke_customers():
      return balances.filter(balance => balance  balance  score > 100)
      return bs.intersect(cs).keys()

In the end, most queries are "just" set theory ... and having a very thin disc io layer allows to use the host language to process queried data on the fly.

It's very basic ... and does not address performant views, clustering, migration, etc ... but it's simple ... and does work well as demonstrated by the ECS systems in game development (which are an application of the concept).

(Sidenote: that's some messed up pseudocode ... I've been working with C#, Python and Haskell lately :-) )

Re: We Can Do Better Than SQL

#209

Post by viraptor » Tue, Aug 11, 2020, 10:01 AM UTC

isatty wrote: post #170

seer wrote: post #129

I for one would welcome a new alternative to sql. It might not be _this_ alternative, but why not try. SQL is very hard to learn properly, with all of its gotchas and inconsistencies. There are running jokes for noobs truncating their tables due to forgetting a where clause. I’ve seen junior devs crying in tears and throwing their mice just because they needed to debug / optimise a complex query. The mare existence o…

> SQL is very hard to learn properly, with all of its gotchas and inconsistencies. I don't understand why though? I've been using SQL (Postgres for the most part but with a smattering of MySQL thrown in) for around 8(?) years, which isn't much in the grand scheme of things but I have not had anything that couldn't be resolved. I've written small straightforward queries to over 200 loc and never had a problem understa…

I'd rearrange the list a bit to what I see experienced devs do, and I don't see a problem with it:

1. Lets use an ORM because it'll be easier

(skipping 2, because it's not really a mess; skipping 3, because they know that before getting to this point)

4. Run that through EXPLAIN ANALYZE

5. Can't make the ORM do that

6. Use native query

7. Profit

There's nothing wrong with having `Users.active.find(id)` where you want it and writing out the complex query as SQL where it gets complicated. They can live next to each other just fine and still improve your life.

Going extreme in any direction is going to cause problems. (whether 100% ORM, or SQL purity) It's fine to use different approaches where they're appropriate.

Re: We Can Do Better Than SQL

#210

Post by dsego » Tue, Aug 11, 2020, 10:03 AM UTC

marmada wrote: post #203

I see a lot of Stockholm syndrome in this thread / maybe low expectations. Many people are saying SQL isn't that hard to learn but as someone who is new to SQL, I disagree. It takes a max of 15 minutes to understand basic JavaScript/Go/Python primitives and write a program. SQL on the other hand seems much more complex. I might as well be reading Haskell or Lisp. At least those languages are consistent. SQL does not…

People who learn the nitty-gritty details and all the gotchas and tricks in the book, appear to be experts and their job positions depend on it. It's all a bit "ludditic", people confuse this familiarity with arcane commands and proficiency with real expertise and deep knowledge. When you challenge that, you challenge their existence. Knowing how null behaves (Null = null vs null is null) is one of those shibboleths that differentiates an sql wizard from a lowly commoner, like knowing all the nuances of prototype inheritance makes one a true JS champion. These people charge a pretty penny to optimize badly written sql queries and fix your joins. And you want to take that away from them.