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

191–200 of 466 posts

Re: We Can Do Better Than SQL

#191

Post by grandinj »

SQL was designed by COBOL / NATURAL people and was intended to be used by "normal people". That was part of a larger movement at the time to make programming more accessible. Unfortunately (a) that experiment mostly failed (b) the resulting syntax does not compose well at all (c) the syntax does not represent the underlying semantics and mathematical operations well at all.

The combined effect is a rather tortured language, as it has been extended over the years.

However, replacing it is equally problematic because of the huge installed base.

Re: We Can Do Better Than SQL

#192

Post by kybernetikos »

agumonkey wrote: post #110
enjo wrote: post #89

Earlier quoted context omitted.

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

Not a munroe original, but I like this one https://thomaspark.co/2017/01/relevant-xkcd/

Re: We Can Do Better Than SQL

#194

Post by Flimm »

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 SQL query string like this:

  conditions = " AND ".join(filter_key + " = '" + filter_value + "'" for kilter_key, filter_value in filter.items())
  order_by = column_name + " DESC"
  query = "SELECT col1 FROM tablename WHERE " + conditions + " ORDER BY " + order_by
But this has multiple SQL injection vulnerabilities. Doing it correctly is not just a matter of using SQL parameters, because column names need to be escaped differently than string literals. Linters can't distinguish between correctly escaped queries and incorrectly escape queries in non-trivial cases. Also, the query will throw a syntax error if the number of filters is zero, since you can't have an empty WHERE clause.

I don't think a new query language solves this problem.

Re: We Can Do Better Than SQL

#195

Post by ideamotor »

roenxi wrote: post #181
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. > 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…

Please use pivot_wider and pivot_longer instead of gather and spread. The true horror, even admitted by the the dplyr team ...

Re: We Can Do Better Than SQL

#196

Post by Zamicol »

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…

What is a good "web scale" solution?

Re: We Can Do Better Than SQL

#197

Post by maweki »

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…

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.

Re: We Can Do Better Than SQL

#198

Post by S_A_P »

I sometimes don’t love sql especially when debugging a huge script of dynamic sql that was only partially scripted to generate the actual sql that is executed and there are between 1500 and 5000 lines to sort through. But you get used to it.

Re: We Can Do Better Than SQL

#200

Post by goto11 »

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.

I love SQL but I still think we can do better! The strength of SQL is the underlying relational model and relational algebra. Syntax wise SQL is somewhat clunky.

Linq in .net shows IMHO how queries can be expressed in a more consistent and composable syntax while still conforming to the relational model.

Post reply on HN