Live data from Hacker News

We Can Do Better Than SQL

edgedb.com

181–190 of 466 posts

Re: We Can Do Better Than SQL

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

> 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? Is "day from timestamp '2001-02-16 20:38:40'" the argument? Are the arguments "day", "timestamp" and "'2001-02-16 20:38:40'"?

Are these annoyances crippling? Yes. Yes they are crippling. It should be possible for an amateur to quickly write an SQL validator as a starting project; relational algebra is not complicated. Any fool can write a validator for lisp. Relational algebra isn't that much more complicated - we don't have loops or flow control to contend with here.

Tidyverse's dplyr [0] implements the relational model for real dirty data and, as might be expected for something implemented this century, does a much better job than SQL. Not because the operations are that much different (although gather() & spread() are welcome additions) but through ingenious innovations like, as mentioned, functions having arguments instead of I-don't-even-know-what-that-is.

And the pipe operator which is legitimately ingenious. Great operator for data.

[0] https://dplyr.tidyverse.org/reference/index.html

Re: We Can Do Better Than SQL

#182
post #2

Would be nice, but bazillions of lines of SQL at the core of almost every business system make this as likely as “We can do better than five fingers.” The article does nicely illustrate many of the well-known shortcomings of SQL. Chris Date and Hugh Darwen unsuccessfully tried to fix SQL with Tutorial D. Never heard of it? Exactly.

Maybe just have SQL Transpilers? I mean we accept ORMs, so we should accept that.

There’s a lot of that in the GraphQL space at the moment. Prisma, Hasura, Postgraphile, EdgeDB, etc...

Re: We Can Do Better Than SQL

#183
post #170
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…

In my experience people who have trouble with ORM usually try to use it for something which it is not well suited for: namely OLAP.

ORM can really get in the way when you want to express groupings, aggregates, and all kind of joins sprinkled with let's say stored procedures.

But this has nothing to do with the ORM itself. It's just a fact that many people don't understand/consider the tradeoffs before jump into acting on something.

Re: We Can Do Better Than SQL

#184
post #93

Am I the only full stack dev that likes SQL? SQL is an incredibly expressive and flexible way to read, store, and update data. It's ubiquitous, so the SQL skills I learned six jobs and three industries ago are still relevant and useful to me today. Relational Databases and SQL are heavy lifters that I often relay upon to build projects and get things done.

Same for me, even more after venturing into the NoSQL hype of the early 2010s, I implemented pretty successful systems using non-relational databases but over time I stick to a RDBMS as most and as far as I can.

Not only I prefer to work with SQL nowadays I also prefer SQL over any ORM in older codebases, ORMs are pretty useful for getting up to speed without caring about your persistence layer too much but after 17 years in this industry I've had my fair share of issues with ORMs to avoid them whenever I can.

Native SQL queries with placeholders for my parameters in their own files, loaded by my database driver to execute and return data is my go-to solution for data access, it's flexible, maintainable and readable if you treat SQL as your normal code (code reviews, quality standards, etc.).

Re: We Can Do Better Than SQL

#185

Can you model this in EdgeQL? https://developer.mongodb.com/community/forums/t/is-this-que... Area of curiousity at the moment as I too agree that SQL is a poor fit, even if the better DSL inputs eventually get reduced to SQL command text and parameter arrays.

This was written on my mobile, so haven't had a chance to test it, but here's my first pass at modelling it in SQL:

  select sum( case when prev_cust.cust_id is null then 1 else 0 end) / sum( april_cust_count ) as pc_new_cust
  from (
    /* get unique customers in April */
    select distinct cust_id, 
        1 as april_cust_count
    from orders
    where order_date between date '2020-04-01' and date '2020-04-30'
  ) as april_cust
  left join
  (
    /* get customers with a transaction prior to April */
    select distinct cust_id
    from orders
    where order_date 
Apologies for the lack of code formatting... I find that when SQL is written with a nice formatting (e.g. Nested sub queries with tabs) it reads a whole lot better.

Re: We Can Do Better Than SQL

#186

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…

GraphQL and SQL are not mutually exclusive at all. GraphQL is, in no way, faster than any REST alternative in terms of implementation speed. If anything, it is slower, as you need to be extremely methodical with your API changes, as (same with REST I suppose) deprecating fields / entities, for mobile clients specifically, is a PITA unless your clients have really nicely built out forced upgrades. What GraphQL _does_…

MVP? Just use your apollo/GraphQL server as the node monolith and be done with it.

Re: We Can Do Better Than SQL

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

Are you thinking of Datalog?

Re: We Can Do Better Than SQL

#188

Earlier quoted context omitted.

At work we almost exclusively use pure stored procedures[1] and everything is normalized very well. It is an absolute joy to write SQL, because of how terse it is while still being very readable. Trying to implement business rules about data relations outside of the DB is a nightmare. [1] We use dynamic SQL within stored procedures for pivots.

You lose source control on your procedures. How you deal with that?

Why? When I worked doing infrastructure and CI/CD automation we created a pipeline for deploying stored procedures, not that different from any other code lifecycle process.

Re: We Can Do Better Than SQL

#189

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…

GraphQL and SQL are not mutually exclusive at all. GraphQL is, in no way, faster than any REST alternative in terms of implementation speed. If anything, it is slower, as you need to be extremely methodical with your API changes, as (same with REST I suppose) deprecating fields / entities, for mobile clients specifically, is a PITA unless your clients have really nicely built out forced upgrades. What GraphQL _does_…

I have seen startup using GraphQL for mvp, precisedly because they could change and crank ui fast. They already knew GraphQL, I did not when I joined and learned to modify already existing one in a day or so.
Post reply on HN