Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Against SQL (2021)

scattered-thoughts.net

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Against SQL (2021)

#51

Post by j45 »

bruce511 wrote: post #9
j45 wrote: post #6

Earlier quoted context omitted.

Trying to understand how the year is relevant - still new to folks and still seems relevant.

It's helpful to include the year in the article header because; Everything may have been true at the time of writing, but details may be obsolete. For example this article refers to Neo4j. Knowing the article is 4 years old helps me understand that comment is not current. The landscape can change quickly. The older an article the more one takes that into account. Given that this article promotes an alternative techni…

The year can help for sure - is the article's content still relevant and current in your mind?

On one hand SQL, is the most established relational db. Not sure what might drastically change about.

Python and Javascript are from the 90’s and have evolved as a language in their own way like SQL and others.

I was asking about the year as an individual comment here to understand what significance the year relative to the content of the topic it bore.

Re: Against SQL (2021)

#52

Post by JaggerFoo »

SQL is great. I've used it to implement knapsack optimization for Daily Fantasy Sports at scale. I use it in Big Data tools and RDBMS. It's pervasive in data tech.

Feel free to innovate and bring forth other RDBMS/Data query languages and tools, perhaps something may succeed and stick as long as SQL has.

Cheers

Re: Against SQL (2021)

#53

Post by YZF »

nawgz wrote: post #20
YZF wrote: post #7

In my day job the question of SQL and its role keeps coming up. Some people want to propagate SQL all the way to clients like web browsers. Perhaps operating over some virtual/abstract data and not the real physical underlying data (that's a whole other layer of complexity). This seems like a bad idea/API in general. I'm not too familiar with GraphQL but on the surface it seems like another bad idea. Shouldn't you al…

Re: GQL - Explain to me what abstraction layer should exist between the data model and what data is loaded into the client? I’ve never understood why injecting arbitrary complexity on top of the data model is wise. Perhaps unfettered write access has its problems, and GQL has permissions that handle this issue plenty gracefully, but I don’t see why your data model should be obfuscated from your clients which rely on…

In my view the abstraction layer should be in the domain of the application.

Let's say your software is HR software and you can add and remove employees. The abstraction is "Add an employee with these details". The data model should be completely independent of the abstraction. I.e. nobody should care how the model is implemented (even if in practice it's maybe some relational model that's more or less standard). Similarly for querying employees. Queries should not be generic, they should be driven by your application use cases, and presumably the underlying implementation and data model is optimized for those as well.

But I get it the GQL can be that thing in a more generic schema-driven thing. It still feels like a layer where you can inadvertently create the wrong contract. Especially if, as I think the case is, that different teams control the schema and the underlying models/implementation. So what it seems to be saving teams/developers is needing to spell out the exact requirements/implementation details of the API. But don't you want to do that?

How do people end up use GQL in practice? what is the layer below GQL? Is it actually a SQL database?

Re: Against SQL (2021)

#54

Post by lawrencejgd »

throwaway894345 wrote: post #36
thom wrote: post #21

[flagged]

SQL itself doesn't generate any value, relational databases generate value. SQL is just a frontend for them. Anyway, your snark could be applied to _literally any change_. Are you angry that cars are replacing horses? "Horses generate such incomparable value that there's a steady supply of pro-car posts, like fumes from the vast ocean of their constantly boiling piss". Don't like the cotton gin? "Slave labor generate…

I think here applies very well this quote: All right, but apart from sanitation, medicine, education, wine, public order, irrigation, roads, the fresh-water system and public health, what have the Roman (SQL) ever done for us?

Re: Against SQL (2021)

#55

Post by jampekka »

sema4hacker wrote: post #38

For any language as large and complicated as SQL, it's easy to come up with a long list of design problems. The difficulty is designing something better, and then even more difficult than that is getting people to use it.

Much of the critique is that it's large and complicated because of bad design.

"Because SQL is so inexpressive, incompressible and non-porous it was never able to develop a library ecosystem. Instead, any new functionality that is regularly needed is added to the spec, often with it's own custom syntax. So if you develop a new SQL implementation you must also implement the entire ecosystem from scratch too because users can't implement it themselves.

This results in an enormous language."

Re: Against SQL (2021)

#56

Post by geysersam »

zkmon wrote: post #14

So I guess the author is trying to help a decision maker to make a decision when faced with a question of whether to use SQL or not. But in reality that question would be settled by other factors and contextual reasons rather than the arguments provided by the author. For instance, analytics usecases favor SQL stores, as slicing and dicing is better done with row or column stores instead of document databases. Also,…

> So I guess the author is trying to help a decision maker to make a decision when faced with a question of whether to use SQL or not.

That's not my impression. A decision maker today should typically make the decision to use SQL. I'm pretty sure the author would agree with that.

I think the target audience is language designers and tool builders. The author is urging people to envision and build new better interfaces to interact with relational data.

Re: Against SQL (2021)

#57

Post by woooooo »

throwaway894345 wrote: post #36
thom wrote: post #21

[flagged]

SQL itself doesn't generate any value, relational databases generate value. SQL is just a frontend for them. Anyway, your snark could be applied to _literally any change_. Are you angry that cars are replacing horses? "Horses generate such incomparable value that there's a steady supply of pro-car posts, like fumes from the vast ocean of their constantly boiling piss". Don't like the cotton gin? "Slave labor generate…

SQL as a query description language absolutely brings its own value.

We had a whole period of NoSQL because its difficult to shard SQL out across distributed databases, followed by people figuring out how to make SQL work on distributed databases, because SQL is really useful and people like it.

Re: Against SQL (2021)

#58

Post by mulmen »

3eb7988a1663 wrote: post #43
procaryote wrote: post #4

TL;DR; * a list of things they don't like in sql * a list of traits they think a replacement should exhibit by negating the first list I was kind of hoping for some example of what this much better language should look like

I like PRQL[0] - fixes stupid warts about SQL. A few top line items: - trailing commas not an error - queries can be read/written in linear order, starting with from, and ending on select - trivial intermediary keywords (eg you define month_total, and then can re-use month_total in a following calculation, no need to duplicate the calculation logic) - no need for a separate `having` keyword when `where` can just be a…

> trivial intermediary keywords (eg you define month_total, and then can re-use month_total in a following calculation, no need to duplicate the calculation logic)

Postgres already has this.

Re: Against SQL (2021)

#59

Post by grebc »

gavinray wrote: post #34

I work at (what was previously known as) Hasura. Specifically: the connector bits that deal w/ translating Relational Algebra IR expressed as GraphQL nodes -> SQL engine-specific code. The author's comments about lack of standardization and portability might not get across just how nightmarishly different SQL dialects are. I might put together a list of some of the batshit-insane bugs we've run into, even between ver…

It’s not a small decision to switch database vendors.

Worrying that your data query language works across multiple vendors DB’s is not a concern ever considered imho.

Re: Against SQL (2021)

#60

Post by jaredklewis »

jampekka wrote: post #55
sema4hacker wrote: post #38

For any language as large and complicated as SQL, it's easy to come up with a long list of design problems. The difficulty is designing something better, and then even more difficult than that is getting people to use it.

Much of the critique is that it's large and complicated because of bad design. "Because SQL is so inexpressive, incompressible and non-porous it was never able to develop a library ecosystem. Instead, any new functionality that is regularly needed is added to the spec, often with it's own custom syntax. So if you develop a new SQL implementation you must also implement the entire ecosystem from scratch too because us…

I would say that’s just another trade off though, in that extensibility and portability are invariably in tension.

The article simultaneously complains that the SQL standard is not universally implemented (fair) and that SQL is not easily extensible (also fair). But taken together it seems odd to me in that if you make SQL very extensible, then not only will it vary between databases, it will vary between every single application.

Also, the line between SQL and database feels a little fuzzy to me, but don’t a lot of postgresql extensions effectively add new functionality to SQL?

Post reply on HN