Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We Can Do Better Than SQL

edgedb.com

Post reply on HN
Print view View original

31–40 of 466 posts

Re: We Can Do Better Than SQL

#31

Post by waheoo »

gregjor wrote: 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.

You can pry SQL out of my cold dead hands. Its just not that bad.

Re: We Can Do Better Than SQL

#32

Post by ckocagil »

I'm not impressed for two reasons:

1. Anyone striving to build a better SQL should make a comprehensive list of common (but difficult!) database tasks for OLTP and OLAP workloads. This will expose the weakness of their language. SQL has had 50 years and myriads of improvements to cover all these common cases. This is not a fair fight, so come prepared.

2. It's not enough to be just "better than SQL" to replace it. SQL has such a huge momentum that a new language needs to be absolutely better _and_ it should have many features that SQL cannot possibly have. My nice-to-have list would contain predictable performance, lock ordering, ownership relations (for easy data cleanup), and a standard low level language which the query optimizer would output.

Re: We Can Do Better Than SQL

#33

Post by RedCrowbar »

querylangs2020 wrote: post #8

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.

> Can you model this in EdgeQL?

Absolutely!

  WITH
    april := '2020-04-01T00:00+00',

    NewCustomers := (
      SELECT Customer
      FILTER
        NOT EXISTS (
          SELECT .orders
          FILTER .date
This assumes the following schema:

  type Order_ {
     property date -> datetime;
  }

  type Customer {
     multi link orders -> Order_;
  }

Re: We Can Do Better Than SQL

#35

Post by ckocagil »

jimbob45 wrote: post #9

I was looking around yesterday to find alternatives to SQL and found nothing. Everything is in this ridiculous table-based model, the queries of which are complicated and error-prone. It’s heresy to criticize SQL these days or even suggest that DBs could be easier and more robust. I envision a future DB language that offers perfect ease and safety with queries the way Rust has shown us that the memory unsafeness of C…

Did you come across Datalog?

Re: We Can Do Better Than SQL

#36

Post by exabrial »

Honestly I think SQL is pretty easy. I love it. I can teach the basics to a new person in minutes.

You know what we could do better at? Crappy explains from database engines. Crappy rate limiting capabilities. Poor feedback on keep cache pipelines fed during scans. Poor feedback on column size effects on reading stripes from disk and size alignments between the filesystem and database.

Re: We Can Do Better Than SQL

#37

Post by dragonwriter »

nerdponx wrote: post #27
dragonwriter wrote: post #26

Earlier quoted context omitted.

> Chris Date and Hugh Darwen unsuccessfully tried to fix SQL with Tutorial D. Well, just the D class of languages; Tutorial D is (as the name suggests) a pedagogy-focusses implementation of the D requirements, the intent was that there would be one or more Industrial Ds. (Dataphor is a D—the first implemented, IIRC—and is successful enough that it's a still-living commercial product.)

I assume this is different from the D programming language?

Date and Darwen’s D class of languages unifying the OO and relational models are different from Walter Bright’s “what C++ should have been” D language, yes.

Re: We Can Do Better Than SQL

#39

Post by peter_mcrae »

oblio wrote: post #30
gen220 wrote: post #17

Earlier quoted context omitted.

> The NoSQL movement was born, in part, out of the frustration with the perceived stagnation and inadequacy of SQL databases I'm a little bit young, but isn't this a bit of a revisionist take, by the author? I thought that Amazon, Google, FB et al moved away from relational databases because the sharding logic they needed to build on top of these databases was approaching the complexity of a RDBMS. They didn't need s…

Isn't NoSQL at this point used in 99% of the cases for basically analytics on logs, especially for ads?

That is probably true. But, I'd also suspect that in 99% of cases some form of that data (lots of post processing) ends back in data store where all kinds of people use SQL to analyze it. Two main reasons: 1) join it with other data 2) SQL is so widely understood across functions / roles

Re: We Can Do Better Than SQL

#40

Post by chx »

mr_toad wrote: post #10

> The NoSQL movement was born, in part, out of the frustration with the perceived stagnation and inadequacy of SQL databases. I would dispute this. The antecedents of NoSQL were the parallel programming models of HPC. They weren’t specifically excluding SQL, and NoSQL was a term that was invented after the fact.

> The antecedents of NoSQL were the parallel programming models of HPC.

Can you elaborate on what you are thinking of? As a refresh, here's when and how the (current usage at least) of NoSQL was introduced: https://subscription.packtpub.com/book/big_data_and_business... in 2009.

> As Oskarsson had described, the meeting was about open source, distributed, non-relational databases, for anyone who had "… run into limitations with traditional relational databases…," with the aim of "… figuring out why these newfangled Dynamo clones and BigTables have become so popular lately."

I was using MongoDB at the time (we became one of their first paying customers -- they didn't even want to take money for support at first!) and HPC wasn't in the air. So please elaborate.

http://2009.drupalcamp.at/sessions/chx-session.html as far as I can remember this was my first MongoDB talk. It's been a long time ago.

Post reply on HN