Live data from Hacker News

We Can Do Better Than SQL

edgedb.com

51–60 of 466 posts

Re: We Can Do Better Than SQL

#51

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

Both EdgeQL and SQL disregard the RM proscription about duplicate tuples for practical reasons:

1. Elimination of duplicates from every projection is prohibitively expensive.

2. Sometimes you actually _want_ duplicates to show up without injecting a synthetic key into every projection.

3. There's DISTINCT.

Re: We Can Do Better Than SQL

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

It's 2020 not 1995. There are already lots of good, production-ready SQL alternatives out there. There's full-fledged businesses that have zero lines of SQL.

Re: We Can Do Better Than SQL

#53

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.

An excellent point: there are so many other problems that deserve our attention regarding databases that talking about something that's worked really well for 50 years is kind of silly. We have bigger fish to fry.

Re: We Can Do Better Than SQL

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

It's 2020 not 1995. There are already lots of good, production-ready SQL alternatives out there. There's full-fledged businesses that have zero lines of SQL.

I would like to hear of one such business. Can you give an example?

Re: We Can Do Better Than SQL

#55

I've always wondered if a newer language could be designed with ANSI SQL as a transpilation target, or each of the vendor SQLs as targets. Optimization of queries would be a huge problem, but it always seemed like the only way it would be possible to break out of the SQL hegemony, i.e. first transpile, then start developing native support in the open source databases, then pressure the proprietary databases to adopt…

That's what frameworks like Hibernate or Doctrine do, they have their own object oriented query language that compiles to SQL.

Re: We Can Do Better Than SQL

#56
Overall I like the ideas behind it and the problems with SQL that it solves, at least on a superficially observational level. It could use some real brain bending examples for those of us that deal with difficult data sets.

The tasks needed to actually take over where SQL has left off seem absolutely monumental though. I can't help but think it will never get there, just like every other attempted query language out there.

In my opinion, there are two things that can make SQL 100% better, which wouldn't be a new language, but rather an update to the language standard:

1) algebraic data types, allowing us to get rid of terrible ternary null logic and more closely model real world data domains.

2) a really well thought out date/time API, along the lines of JSR310.

Re: We Can Do Better Than SQL

#57

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…

if NoSQL caused SQL databases to improve, then i'd argue it was a success.

maybe EdgeQL can have the same success by demonstrating improvements that can be added to SQL databases.

Re: We Can Do Better Than SQL

#58

Earlier quoted context omitted.

It's 2020 not 1995. There are already lots of good, production-ready SQL alternatives out there. There's full-fledged businesses that have zero lines of SQL.

I would like to hear of one such business. Can you give an example?

Stripe's primary datastore is mongodb.

Re: We Can Do Better Than SQL

#59

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.

Not only this, but resources GALORE since its been around longer than the internet and has been used by just about every developer. Java, Python, C#, Node, PHP etc... they all know SQL.

Re: We Can Do Better Than SQL

#60
post #47
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 AN…

I only had a quick look, is it a computer-friendly offshoot of relational algebra[1], the actual mathematical model for relational databases, as an actual query language?

[1]https://en.wikipedia.org/wiki/Relational_algebra

Post reply on HN