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

101–110 of 466 posts

Re: We Can Do Better Than SQL

#101

Post by mathgladiator »

julochrobak wrote: post #82

I am a big fan of a relational model. SQL itself is OK but far from great. So, I wish you a lot of success! I was part of a similar attempt - building a better "SQL" and relational DB. This was roughly 8 years a go. You can have a look at our GitHub Projects or look at some further links and may be you get inspired :) * http://bandilab.github.io/ - introduction to the bandicoot project * https://www.infoq.com/present…

bandicoot looks interesting, and it feels spiritually related to a project I'm working on. I'm designing a programming language for board games: http://www.adama-lang.org/

Re: We Can Do Better Than SQL

#102

Post by garmaine »

anyfoo wrote: post #60
nealabq wrote: post #47

Earlier quoted context omitted.

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

Relational algebra is functional programming: you map-reduce your way to a solution set.

Relational calculus is logical programming: you specify what the solution looks like and the query engine figures out the sequence of operations to find a solution.

Re: We Can Do Better Than SQL

#103

Post by uhoh-itsmaciek »

jldugger wrote: post #24
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…

> I thought that Amazon, Google, FB et al moved away from relational databases because the sharding logic they needed to build Note that these companies did not move away from relational DBs until long after the "NoSQL is Web Scale" video. Yes, Google invented Big Table to help power search (and others), but their revenue system, AdWords, didn't move off MySQL until like 2015. And last I checked, Facebook is still a…

>These days you can even just tune pgsql to support kv store formats

And you can turn off fsync! Though if you do, disable synchronous_commit instead for most of the performance but none of the potential data corruption (you're still risking data loss, of course, just not corruption).

Re: We Can Do Better Than SQL

#105

Post by throwaway_pdp09 »

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

What you (and I) like is not SQL per se but what comes through of the underlying relational model, that SQL hasn't screwed up. SQL as a syntax and semantics is a mess. It could have been better.

Re: We Can Do Better Than SQL

#106

Post by unodgs »

mathgladiator wrote: post #96
bjo590 wrote: 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.

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…

Recently I tried using SQL directly on the frontend: https://medium.com/@unodgs/sql-on-the-frontend-react-postgre... as an alternative to GraphQL which I also find too complicated. You might find this interesting.

Re: We Can Do Better Than SQL

#107

Post by mnsc »

CaptainZapp wrote: post #94
AmericanChopper wrote: post #75

Earlier quoted context omitted.

> Predictable performance - this will always be not only implementation-dependent but data-dependent as well This immediately jumped out at me from the parent comment. It would be entirely possible to implement a query language where you specify a plan for your query. But then you’d immediately lose the “better than SQL” competition, because your complexity and maintainability problems would skyrocket. I’ve had to de…

I wish that I could upvote your comment more than once, because this rings so true. There certainly are (rare) situations, where you need to provide hints in one form or another, but it's really a bloody nightmare to maintain and may completely bork, when you - say - upgrade to a new version of the database engine. I work with relational databases since the early 90s and can give you a no-bullshit money back guarante…

I think one of the challenges with sql is that beginner developers can create naive sql queries that "work" but are extremely complicated for the optimizer to "get right". So in some cases (talking from own experience) the developer can, with the use of hints, "be better" than the optimizer when the problem all along was the overall structure of the query.

Edit: don't do it

Re: We Can Do Better Than SQL

#108

Post by throwaway_pdp09 »

okaleniuk wrote: post #104

Ergonomics of a language I don't know is always worse than that of I do know. As long as there's nothing valuable in the technology itself why would I bother changing things?

> As long as there's nothing valuable in the technology itself

You're assuming there's nothing valuable. I'd say there is. Whether that's enough to displace SQL I really doubt.

Re: We Can Do Better Than SQL

#109

Post by linuxhansl »

SQL is also an unfortunate mix of relational calculus and relational algebra. The two can be shown to be equivalent.

While in calculus you declaratively describe the set of data you want and let the system figure out how to get it, in the algebra you describe how to construct the set you want.

With that in mind SELECT ... WHERE ... is calculus, UNION and JOIN, etc. are algebra.

I like SQL, though.

Re: We Can Do Better Than SQL

#110

Post by agumonkey »

enjo wrote: post #89
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…

XKCD’s comic on competing standards feels appropriate here: https://xkcd.com/927/

is xkcd ever not appropriate ? there's probably an xkcd about it
Post reply on HN