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

111–120 of 466 posts

Re: We Can Do Better Than SQL

#111

Post by wmichelin »

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…

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_ give you, is type safety and extreme client flexibility . It is a better solution than REST in almost every scenario, other than the initial learning curve, which takes a couple weeks and then you know it forever.

Would I recommend some startup write a GraphQL API for their MVP? No, just get something working. Are you at a more medium-sized company looking to build out your much more permanent API? Then yes, you should probably strongly consider GraphQL.

Re: We Can Do Better Than SQL

#112

Post by agumonkey »

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.

how many devs accept it for what it is, limits included ?

it's alright, it's consistent enough, it's good

I'm reading about datalog and prolog more and more but sql is ok

Re: We Can Do Better Than SQL

#113

Post by simonw »

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.

I've been experimenting with SQL as an API language - including client-side SQL constructed in JavaScript - fir a couple of years with my Datasette project.

I'm using similar security tricks to you: read-only queries with a time limit, against SQLite rather than PostgreSQL.

More here: https://simonwillison.net/2018/Oct/4/datasette-ideas/ and https://github.com/simonw/datasette

Re: We Can Do Better Than SQL

#114

Post by aspyct »

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.

Totally with you, long live SQL!

Re: We Can Do Better Than SQL

#115

Post by danielovichdk »

bjo590 wrote: post #90
simonbarker87 wrote: post #64

Earlier quoted context omitted.

Your brain must work different to mine. SQL is by far the hardest tool I use. I’ve used all the main languages from asm up to js for real work and nothing breaks my brain like SQL. I use it daily in a business that is heavy on SPs and while I get by and am improving the jump from inner joins and selects to CTEs and the other wizardry is massive. I want to be better at SQL but so many problems I hit up against and thi…

> I want to be better at SQL but so many problems I hit up against and think “well that’s a 2 minute job in js/swift/php” The thing about SQL is that it's the fastest way to read&write data in a relational database. Maybe writing the code is faster in js/swift/php, but the code will run faster in SQL. If you need to do something to 100M pieces of data you can do a lot worse than SQL.

You cannot compare SQL to either of those languages, since they are not built solely for data for data manipulation, but also a lot of other things, which SQL is not. SQL can do a lot too, but just because you e.g can do formatting in SQL doesn't Mean it's the correct place or choice.

Re: We Can Do Better Than SQL

#116

Post by lmm »

bjo590 wrote: post #90
simonbarker87 wrote: post #64

Earlier quoted context omitted.

Your brain must work different to mine. SQL is by far the hardest tool I use. I’ve used all the main languages from asm up to js for real work and nothing breaks my brain like SQL. I use it daily in a business that is heavy on SPs and while I get by and am improving the jump from inner joins and selects to CTEs and the other wizardry is massive. I want to be better at SQL but so many problems I hit up against and thi…

> I want to be better at SQL but so many problems I hit up against and think “well that’s a 2 minute job in js/swift/php” The thing about SQL is that it's the fastest way to read&write data in a relational database. Maybe writing the code is faster in js/swift/php, but the code will run faster in SQL. If you need to do something to 100M pieces of data you can do a lot worse than SQL.

That's circular reasoning though. Why do you want your data to be in a relational database? Particularly if you're not actually using its features (I don't think I've ever seen a web application that actually got any value out of database-level transactions, for example). A different kind of datastore could offer you better performance and easier querying.

Re: We Can Do Better Than SQL

#117

Post by yen223 »

CaptainZapp wrote: post #95
dman wrote: post #70

One word of caution to those trying to improve on SQL - for the many users of SQL, technology is a secondary aspect of their jobs. Hence any replacement runs into the issue that many of its core users do not have the bandwidth to spend significant effort on learning another querying language. I will cheer everyone who tries to displace SQL, because I do think it needs to be displaced but would also want to caution su…

> I will cheer everyone who tries to displace SQL Why? What are better alternatives, really?

There's a non-trivial number of live running systems out there that interact with RDBMSes entirely through either ORMs or query builders, without a single line of programmer-written SQL. Those systems seem to hold up well.

Re: We Can Do Better Than SQL

#118

Post by sfvisser »

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.

Not sure that is true. You can imagine having a smaller query language with clean semantics able to capture messy data relationships. Small functional expression languages come to mind. Where it lies on the spectrum from purely-table-form to can-hold-everything is a design choice.

Your query language doesn’t need to capture the underlying data model exactly. SQL is an example of this itself.

I’ve run into the orthogonality issue myself several times. You don’t need to drop SQL today, but for some data domains more expressive query models can work really well.

Re: We Can Do Better Than SQL

#119

Post by chime »

_nhynes wrote: post #99
bjo590 wrote: post #83

Earlier quoted context omitted.

I often think that a great way to displace SQL would be to create a language that compiles to SQL similar to how TypeScript compiles to Javascript.

You mean like an ORM?

ORMs I've worked with usually expect you to write the complex queries/joins yourself using a series of functions e.g. orm.select(table1).join(table2).on(keys).where(cond).group(by).having(cond).order(by). It's just SQL with extra steps.

An ORM that understands db schema, indices, and automatically decides where to use outer join or subqueries based on what would be most efficient given the specific schema would be fantastic. Basically an ORM that 95% of the cases comes up with the most efficient way to look up the data.

Re: We Can Do Better Than SQL

#120

Post by quickthrower2 »

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 was hoping for something more left field myself. If SQL is based on tables, what about a QL based on relations only. Columns of data that are related, the "TABLE" implementation detail doesn't need to factor into it.
Post reply on HN