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

41–50 of 466 posts

Re: We Can Do Better Than SQL

#41

Post by hota_mazi »

The last technology that attempted this task was NoSQL, and we all know how that ended.

First, people realized that schemas (just like static types) are extraordinarily important for robust software.

Second, NoSQL lost to SQL over the long run in pretty much all dimensions: query language, performance, scalability, concision, etc...

As a result, not only is NoSQL on the way out, but SQL databases have actually become better at supporting NoSQL features than any NoSQL database.

SQL didn't just win, it absorbed its opponent and became even better as a result. Never underestimate the versatility and adaptiveness of a technology.

Re: We Can Do Better Than SQL

#42

Post by mapgrep »

jugg1es wrote: post #7

SQL is definitely not perfect but it's supported everywhere and integrates with everything, so you can augment it with other languages. That fact makes a lot of the critiques sort of moot.

Yup. The fact that it has been around for 46 years and dominant in its problem space for most of that time is pretty compelling too. In the 90s it was going to be replaced by object databases, said the hype. In the aughts it was up against Mongo and Couch and the like. The pretenders to throne keep coming and going.

Re: We Can Do Better Than SQL

#43

Post by talaketu »

> In EdgeQL every value is a set

This is trouble for the example for calculating the average number of reviews across movies:

   SELECT math::mean(
       Movie {
          description,
          number_of_reviews := count(.reviews)
      }.number_of_reviews
   );
Never mind, they are not sets:

> Strictly speaking, EdgeQL sets are multisets, as they do not require the elements to be unique.

The relational model is firmly based on the idea of a relation as a "set of tuples", and a major criticism of SQL has been that it views data as an ordered sequence of tuples.

So I'm skeptical of the claim that EdgeQL is really based on the relational model.

(Not clear whether multisets are ordered - wondering about window functions etc...)

Re: We Can Do Better Than SQL

#44

Post by aplummer »

hota_mazi wrote: post #41

The last technology that attempted this task was NoSQL, and we all know how that ended. First, people realized that schemas (just like static types) are extraordinarily important for robust software. Second, NoSQL lost to SQL over the long run in pretty much all dimensions: query language, performance, scalability, concision, etc... As a result, not only is NoSQL on the way out, but SQL databases have actually become…

> The last technology that attempted this task was NoSQL, and we all know how that ended.

Do you mean billion dollar companies?

Don't get me wrong, wouldn't go near the popular NoSQL databases I've used in the past again, but I sure wish I invented them.

Re: We Can Do Better Than SQL

#47

Post by nealabq »

nealabq wrote: post #25

QUEL ( https://en.wikipedia.org/wiki/QUEL_query_languages ), the original query-language for Ingres, was more orthogonal and consistent than SQL. But IBM decided SQL was more business friendly. Who can argue with that. And before that there was ALPHA. From https://www.labouseur.com/courses/db/s2-Remembering-Codd-2.p... : "Ted [Codd] also saw the potential of using predicate logic as a foundation for a database langua…

Ted Codd designed the Relational Calculus as a clean relational-query language. It looks mathematical (scary?) and a little like a set-comprehension. But I think the big mistake is its use of non-ascii chars like ∃ ∈ ∀.

Here's an example from http://arwan.lecture.ub.ac.id/files/2013/10/4.-relationalcal... :

SQL:

  SELECT DISTINCT F.Name
  FROM FACULTY F
  WHERE NOT EXISTS
    (SELECT * FROM CLASS C
     WHERE F.Id=C.InstructorId AND C.Year=2002)
Relational Calculus:

  {F.Name | FACULTY( F) AND NOT
    (∃C ∈ CLASS( F.Id=C.InstructorId AND C.Year=2002))}

Re: We Can Do Better Than SQL

#48

Post by irjustin »

Seems fitting, XKCD - Standards: https://xkcd.com/927/

The post has weird self faults in its complaints - lack of consistency, and poor system cohesion.

Lack of consistency isn't with the SQL standard, it's with the implementation (this is recognize this later in the post too). Like browsers and the HTML spec - everyone implements the standard SLIGHTLY but non-trivially differently.

poor system cohesion - Being able to integrate/inter-op with every other language literally means poor system cohesion. They're mutually exclusive ideas. This is is why ORMs exist, so there is strong cohesion with a given language.

I'm sad because there's so much work put in here by extremely smart people, but this is a tool looking for a problem. SQL has its shortcomings for sure, but simply replacing it with a slightly cleaner language is not the answer. The benefits do not outweigh the huge amounts of drawbacks that would be required to adopt something like this.

I don't know much about EdgeDB and hopefully there's a lot more benefit I'm not aware of, but purely on the post itself, too many drawbacks.

Re: We Can Do Better Than SQL

#49

Post by querylangs2020 »

RedCrowbar wrote: post #33
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_; }

Thanks. I'm going to dig in a bit more. I've been sold by the above and the homepage.. :)

Re: We Can Do Better Than SQL

#50

Post by riku_iki »

gen220 wrote: post #17
duxup wrote: post #12

As I read this I wondered: "Has anyone fixed these problems elsewhere?" Then: >The NoSQL movement was born, in part, out of the frustration with the perceived stagnation and inadequacy of SQL databases. Unfortunately, in the pursuit of ditching SQL, the NoSQL approaches also abandoned the relational model and other good parts of RDBMSes. Yeah that's what I was thinking, they really don't fix the issues listed, just h…

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

> I thought that Amazon, Google, FB et al moved away from relational databases

Surprisingly, Spanner has tables with columns and you can run SQL on top of it.

Post reply on HN