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

341–350 of 466 posts

Re: We Can Do Better Than SQL

#341

Post by mannykannot »

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 should be possible for an amateur to quickly write an SQL validator as a starting project

> ...why?

I don't know about amateurs, but if the typical intended user of the language does not have a good grasp of what is and is not valid, they will often be reduced to trying one thing after another until they hit upon something that seems to work, with no real understanding of what it does. This is not how robust, correct software is written.

Re: We Can Do Better Than SQL

#342

Post by mannykannot »

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…

You have piqued my curiosity, but what would a linq solution to this exercise look like?

Re: We Can Do Better Than SQL

#344

Post by sumtechguy »

3pt14159 wrote: post #330
jimsparkman wrote: post #315

Earlier quoted context omitted.

WITH (CTEs) make queries so much more readable and digestible. As a programmer who now does data and SQL, I latched on to these as soon as I found I could reduce repetition in a query with them.

For monster queries (thousands of lines of SQL) I find that temporary tables are also great. You can index them and, depending on your DB and its settings, they're usually held in RAM so they're super fast.

That is implementation specific. In some db's putting an index on a temp table does nothing. In later versions of the same db it does but only in particular cases. Make sure you read the docs around that.

Re: We Can Do Better Than SQL

#345

Post by devxpy »

unodgs wrote: post #106
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…

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.

This makes a ton of sense to me, thanks for sharing your learnings.

I see very little value in using GraphQL, when you can just write SQL on the client!

We desperately need frameworks to better facilitate this, like Hasura or Django -- DB migrations, permissions, authentication, real-time subscriptions, Admin UI.

My most wanted feature is SQL type providers, like Rezoom.SQL - https://github.com/rspeele/Rezoom.SQL

Re: We Can Do Better Than SQL

#346

Post by marcosdumay »

lmm wrote: post #239
Akronymus wrote: post #238

Earlier quoted context omitted.

For triggers, you can run a procedure that executes it for all past data. Or write a procedure that updates the data to a valid state. When gradually rolling out, you can have adjusted stored procedures that deal with the different versions, and turn off the old one when it is no longer in use. So, I fail to see the problems you mentioned.

And with good practices (mainly a decent type system that lets you distinguish between checked and unchecked values) you'll have no problems with constraints in the application layer either.

As long as your application layer is a single homogeneous application running the same code.

That is approximately never the case. Current widespread practices are moving away from it, with multi-services, and old fashioned practices of mixing customized and off the shelf tools basically forbid it.

Re: We Can Do Better Than SQL

#347

Post by throwaway894345 »

jolux wrote: post #339
013a wrote: post #336

Earlier quoted context omitted.

A very simple, basic SQL query would be something like "select * from users where foo=bar;" Already, we're introducing a weird inversion of syntax that, in my experience, trips up people learning it: data in SQL is stored as "rows" with "columns" inside "tables". More formally, we've got a hierarchical relationship where Tables > Rows > Columns, yet we write the query as Columns > Table > Rows. There are far more con…

That doesn’t prevent injection, and the solution to injection attacks is using parameterized queries and prepared statements, not switching to MongoDB. Plus ORMs (really query builders) already provide behavior like this against SQL databases anyway.

And those ORMs have to deal with the SQL composability issues as well, often to the effect of dramatically poorer performance.

Re: We Can Do Better Than SQL

#348

Post by ilikehurdles »

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.

Re: We Can Do Better Than SQL

#349

Post by kps »

nealabq wrote: post #309
xiaodai wrote: post #88

Earlier quoted context omitted.

∃ ∈ ∀. quite natural to me as a pure math grad there exists, in, for all

It's a mistake if your goal is to have the language implemented and become popular. Otherwise I like the notation. Computer languages would be different if Ascii had provided code points for ∧ ∨ ∩ ∪ ≡ ↑ etc. It's too bad so much real estate is wasted in the control chars.

\ was invented so that ∧ and ∨ could be written /\ and \/. In retrospect, a mistake.

Original ASCII (1963) had ↑, but it was converted to ^ in 1967 so that it could double as a circumflex.

(Also ←, which was a good assignment operator; it's too bad _ didn't replace \ instead.)

Re: We Can Do Better Than SQL

#350

Post by sanderjd »

mannykannot wrote: post #341
sanderjd wrote: post #289

Earlier quoted context omitted.

> 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 should be possible for an amateur to quickly write an SQL validator as a starting project > ...why? I don't know about amateurs, but if the typical intended user of the language does not have a good grasp of what is and is not valid, they will often be reduced to trying one thing after another until they hit upon something that seems to work, with no real understanding of what it does. This is not how robust, c…

That seems like a completely different point. (Unless I misunderstand what a "SQL validator" is, which is definitely possible.)

I do think this way of utilizing SQL is a problem, but I would lay the blame for it at the feet of a lamentably widespread anti-intellectualism in the field. It is true that the relational model is not trivial and must be learned before SQL makes much sense. But it is not too much to expect from someone who wants to be a practitioner in this field.

Post reply on HN