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

61–70 of 81 posts

Re: Against SQL (2021)

#61

Post by artyom »

woooooo wrote: post #57
throwaway894345 wrote: post #36

Earlier quoted context omitted.

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.

The whole period of NoSQL was particularly sad one. A couple great things emerged from it (Redis etc al) but for the most part it as all smoke and mirrors.

The worst was the amount of people wanting to be the next Ed Codd and being nowhere close to his mathematical background.

Re: Against SQL (2021)

#62

Post by woooooo »

artyom wrote: post #61
woooooo wrote: post #57

Earlier quoted context omitted.

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.

The whole period of NoSQL was particularly sad one. A couple great things emerged from it (Redis etc al) but for the most part it as all smoke and mirrors. The worst was the amount of people wanting to be the next Ed Codd and being nowhere close to his mathematical background.

I'd call it a necessary phase rather than sad. People needed scalability fast, key-value stores are natural to shard, so they did that first and then we got better distributed DBs later. Even Prime Google was on bigtable for over a decade before spanner.

Re: Against SQL (2021)

#63

Post by grebc »

throwaway894345 wrote: post #42
pphysch wrote: post #27

I think "SQL" is fine, whatever, I'm used to working with multiple different query and programming languages and dialects. That includes the freedom to define abstractions over SQL that meet my personal needs. Standard SQL is not helpful, though. If that (failed) experiment was ended, database implementations would have even more freedom to explore superior syntax. Prescriptive language standards are a mistake.

I like that SQL is a standard, and it's mostly "fine". Sure, I have to constantly read the man pages because there are half a dozen different ways to do fundamentally similar things, and there are subtle differences between each vendor, and I keep running into silly errors like trailing commas. But it mostly works. The stuff that is more painful is building any kind of interesting application on top of a database. Fo…

In MSSQL you can select top 0 * into a temp table and retrieve all the usual column meta data.

I’ve written basic custom report writer functionality using this technique that lets users(usually me the developer or a super user) do custom sanitised SQL selects.

I assume similar functionality exists in all the different vendors databases.

Re: Against SQL (2021)

#64

Post by jampekka »

jaredklewis wrote: post #60
jampekka wrote: post #55

Earlier quoted context omitted.

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

The point is that with a more expressive language new features could be added as libraries instead of changing the language itself. This is right before the paragraph I quoted:

"In modern programming languages, the language itself consists of a small number of carefully chosen primitives. Programmers combine these to build up the rest of the functionality, which can be shared in the form of libraries. This lowers the burden on the language designers to foresee every possible need and allows new implementations to reuse existing functionality. Eg if you implement a new javascript interpreter, you get the whole javascript ecosystem for free."

Re: Against SQL (2021)

#65

Post by throwaway894345 »

grebc wrote: post #63
throwaway894345 wrote: post #42

Earlier quoted context omitted.

I like that SQL is a standard, and it's mostly "fine". Sure, I have to constantly read the man pages because there are half a dozen different ways to do fundamentally similar things, and there are subtle differences between each vendor, and I keep running into silly errors like trailing commas. But it mostly works. The stuff that is more painful is building any kind of interesting application on top of a database. Fo…

In MSSQL you can select top 0 * into a temp table and retrieve all the usual column meta data. I’ve written basic custom report writer functionality using this technique that lets users(usually me the developer or a super user) do custom sanitised SQL selects. I assume similar functionality exists in all the different vendors databases.

Yes, you can obviously run queries to get that information, but you can’t do it statically very easily.

> I’ve written basic custom report writer functionality using this technique that lets users(usually me the developer or a super user) do custom sanitised SQL selects.

I’m not sure how having the column metadata helps you sanitize SQL.

Re: Against SQL (2021)

#66

Post by throwaway894345 »

thom wrote: post #46
throwaway894345 wrote: post #36

Earlier quoted context omitted.

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…

If, after 100 years of cars being available, everybody still rode horses and always got where they're going on time, and car people constantly blogged about it, this would be a great analogy.

This comment doesn’t make sense. There are 0 popular relational databases that support SQL and a dialect that addresses SQL’s shortcomings.

Re: Against SQL (2021)

#67

Post by throwaway894345 »

lawrencejgd wrote: post #54
throwaway894345 wrote: post #36

Earlier quoted context omitted.

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?

Not really. That quote is about who pioneered those innovations, not about who perfected them. No one disputes that SQL was first on the scene, we’re disputing whether it can be improved upon and whether the value derived from relational databases is a product of SQL specifically (hint: it’s not).

Re: Against SQL (2021)

#68

Post by jaredklewis »

jampekka wrote: post #64
jaredklewis wrote: post #60

Earlier quoted context omitted.

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

The point is that with a more expressive language new features could be added as libraries instead of changing the language itself. This is right before the paragraph I quoted: "In modern programming languages, the language itself consists of a small number of carefully chosen primitives. Programmers combine these to build up the rest of the functionality, which can be shared in the form of libraries. This lowers the…

Yea I know, I was addressing that in my comment?

You have languages like JavaScript which are very “expressive” in that it comes with very little functionality but there are a wealth of libraries you can use to augment this. And this tradeoff is often lamented on HN since it’s never enough to just know JS; you have to know the particular libraries being used by the project.

Contrast that with batteries included languages like python or go.

And like I said above, Postgres extensions add features to the language, usually without any syntax changes (just new functions or operators). Isn’t this like a “library” in another language?

Re: Against SQL (2021)

#69

Post by nuc1e0n »

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…

To use SQL effectively a certain amount of training is needed. But people are trained to read and write and do arithmatic. How to understand and write simple relational database queries is a broadly useful skill that should be widely taught in schools.

When it comes to written English, perhaps that could do with some reforms just as with SQL. Yet the way we write remains mostly unchanged.

Re: Against SQL (2021)

#70

Post by Izkata »

j45 wrote: post #51
bruce511 wrote: post #9

Earlier quoted context omitted.

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…

It's a HN convention for all posts: If it wasn't from within the past year or so, the year it was posted gets added to the title.

Having to think about it per-topic is just making it more complicated for no good reason. Especially since SQL does get new additions.

People posts comments like that as a reminder because the title originally didn't have it in there, someone edited it in after the comment.

Post reply on HN