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

381–390 of 466 posts

Re: We Can Do Better Than SQL

#381

Post by maweki »

Flimm wrote: post #205
maweki wrote: post #197

Earlier quoted context omitted.

This problem would arise with every DSL. And it has been solved by using embedded DSLs. jOOQ or SQLAlchemy look like SQL (and you don't even have to squint your eyes very much) and solve the problems you mention.

jOOQ and SQLAlchemy are libraries for Java and Python respectively. You can't take your knowledge of those libraries and use them in a different programming language. And you still need to know SQL well in order to do any debugging, because the database is still receiving an SQL query string. What I am wishing for is for the language to be more like JSON, something that matches closely to commonly found structures in…

> jOOQ and SQLAlchemy are libraries

While it is true, they are specifically embedded DSLs, which is exactly what you said you needed. Having a (query) language (a DSL) that is not composed by string concatenation. Embedded DSL solve exactly that problem and they are usually just translations from some DSL into concrete syntax in some programming language, ideally supporting type correctness and preventing syntax errors, etc..

And what you "wish for" is, again, just an embedded DSL, you only wish for you constructors/functions to be native instead of some import/module.

Re: We Can Do Better Than SQL

#382

Post by maweki »

ilikehurdles wrote: post #348
Flimm wrote: post #194

Yes, SQL has flaws, and the article forgot to mention one of them: you need to build a string to build an SQL query, rather than a more structured object, leading to flaws like SQL injection vulnerabilities, and difficulties adjusting the query. Let's say you're building a CRUD app with search and filtering capabilities. Unless you are using an ORM (which has problems of its own), you might be tempted to build the SQ…

You're right that a new query language doesn't solve this. Datalog is over 40 years old, after all.

And we're still researching how aggregation should work. While Datalog is really cool and my PhD research is based on it, the fixpoint semantics really do not work well with aggregation, grouping, etc.

Re: We Can Do Better Than SQL

#383

Post by wtetzner »

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…

I think the real problem is that SQL text is the only interface to most relational databases. There is a SQL standard, of course, but it's difficult to get vendors to implement the standard, because SQL is the user interface to the database.

Instead, perhaps a second format should be standardized, which is machine readable/writable, that more or less represents relational algebra + whatever extra features SQL supports. It can be clunky and verbose, as long as it's straight-forward and easily composable. It would effectively be like a compiler intermediate representation.

Once you have something like that, you can have as many front-ends as you want with whatever syntax you prefer.

Of course, getting all of the RDBMS vendors to agree to it is still a problem, and they'll probably all still include their own vendor-specific extensions and differences, because they want to lock you in to their system.

But at least maybe the open source ones could agree, which would still be quite beneficial.

Re: We Can Do Better Than SQL

#384

Post by no-s »

waheoo wrote: post #31
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.

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

I often joke that SQL is the COBOL of the 21st century. HHOS. There's worse things...e.g. COBOL.

Actually it's very difficult to deny the empirically discernible utility of relational databases and SQL. SQLite, for example.

Re: We Can Do Better Than SQL

#385

Post by 0fcf8d3559a64c »

sanderjd wrote: post #289
roenxi wrote: post #181

Earlier quoted context omitted.

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

> It should be possible for an amateur to quickly write an SQL validator as a starting project ...why? SQL has been wildly paradigm-definingly useful for decades. It has driven hundreds of billions, perhaps trillions, of dollars of value. None of this hinges on the ability for an amateur to be able to write a validator for the language. It just seems like such a non-sequitur to me, such a strange thing to call out as…

>It has driven hundreds of billions, perhaps trillions, of dollars of value.

The same can (almost) be said for Javascript. A language with a lot of foibles can still be successful if it is the only realistic mechanism to interact with the system.

Re: We Can Do Better Than SQL

#386

Post by randomdata »

pkalinowski wrote: post #278
quickthrower2 wrote: post #126

Earlier quoted context omitted.

Anything that uses Activerecord

Isnt ActiveRecord using SQL behind the scenes?

Technically ActiveRecord uses Arel, which in turn compiles, if you will, to SQL. Arel (a strict subset of) could theoretically be an alternative to SQL, if databases supported it as a native language. They don't, so the SQL step is a practical requirement.

This is similar to the browser (especially in the pre-WASM days). No matter what language you actually wrote your software in, eventually you were going to end up converting it to Javascript out of necessity. Would you still say that your program written in C, compiled with emscripten, was written in Javascript?

Re: We Can Do Better Than SQL

#387

Post by Draiken »

wmichelin wrote: post #111
mathgladiator wrote: post #96

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

Too bad nobody thinks whether or not they need the flexibility in the first place. MVPs with single clients using GraphQL for flexibility that is not needed or used are common.

GraphQL is a hammer, and now every project is a nail.

Anecdotal, of course, but the first thing all FE developers I've ever worked with do when they start/join a project is add/suggest GraphQL/Apollo.

Nobody considers how awful things look on the back-end when you need to cache or make magic happen to avoid thousands of N+1 queries.

I believe unfortunately it has become the only way many front-end developers learn to interact with any back-end, and now everyone's forced to use it regardless of its drawbacks.

Same with React. Facebook managed to get free training for all of their future hires. I hate the company but that was a genius move.

Re: We Can Do Better Than SQL

#389

Post by prostodata »

goto11 wrote: post #291
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…

> SQL is messy because describing the underlying data relationships are messy. No, the relational model is beautiful and consistent! SQL is messy because the syntax is not consistent and elegantly composable. It could have those properties and still present the same underlying data relationships. See Linq in C# as an example for how a more composable query syntax can expose the same data model. For example in Linq yo…

> No, the relational model is beautiful and consistent! SQL is messy...

What is beautiful and consistent is the relational algebra. The relation model relies on this formalism to model data by making some rather strong assumptions about how tuples and relations represent things and how relational operations are used to process them. And these assumptions are precisely what propagates to SQL and what some authors (see references in the article) consider controversial and messy. Then the question is whether and how these controversies can be fixed (or whether they are bugs or features).

A radically different approach to fix these controversies is to introduce a different formalism and different data model (as opposed to fixing only syntax) which is based on using functions. In other words, instead of using sets and set operations, we use in addition functions and function operations [1]. Here you can find an implementation of this approach:

https://github.com/prostodata/prosto Prosto is a data processing toolkit radically changing how data is processed by using both sets and functions and being a major alternative to map-reduce, join-groupby and other set-oriented approaches

[1] Concept-oriented model: Modeling and processing data using functions: https://www.researchgate.net/publication/337336089_Concept-o... -> Read introduction (two pages) for why having only sets is not enough and why functions are important

Re: We Can Do Better Than SQL

#390

Post by wtetzner »

achr2 wrote: post #340
goto11 wrote: post #291

Earlier quoted context omitted.

> SQL is messy because describing the underlying data relationships are messy. No, the relational model is beautiful and consistent! SQL is messy because the syntax is not consistent and elegantly composable. It could have those properties and still present the same underlying data relationships. See Linq in C# as an example for how a more composable query syntax can expose the same data model. For example in Linq yo…

I disagree, the relational model is very incongruous with the object model that nearly all LOB applications use. Which is where 99% of the usage issues lie.

That doesn't make the relation model bad, it just means there's an impedance mismatch.

FWIW, I find the relational model to be much nicer than typical object models. Even in Java, which I write every day at work, I've found it to be much clearer to use immutable objects representing records. Not just for interacting with the database, but just for handling information in general.

Of course, it would be extremely painful to do without Lombok's @Value, @Builder, and @With annotations.

Post reply on HN