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

Against SQL

scattered-thoughts.net

Post reply on HN
Print view View original

131–140 of 354 posts

Re: Against SQL

#131

Post by ako »

slx26 wrote: post #67

I think the problem of this essay is that it's overly technical: only those versed well enough in SQL will really care to read the whole thing, and if they are already at that level, either they accepted that "SQL will get the job done in the end", or they learned to live along it and now even kinda embrace it, and are happy to write about how the examples are very poor and dismiss the critique based on that, when th…

There's a lot of talk about what is wrong with SQL, but i haven't seen something yet that is actually better than SQL for most use cases.

Stop fighting SQL so much, and just focus on bringing a better solution. If potential users see it has significant benefits they'll start using it.

Re: Against SQL

#132

Post by ngrilly »

sizzler wrote: post #93

Anybody can criticise SQL, programming languages, etc. It isn't hard and it doesn't make you better than the people that wrote them. When someone says "this thing that has been working fine for decades needs to be completely replaced" and barely mentions any alternative, I don't think they understand the process involved in replacing things or the terrible (non) proposition they are offering. Increment on SQL, write…

When I compare the codebase of a tool like gqlgen (a GraphQL library in Go) with the code base of PostgreSQL or SQLite, I'd say even 10% is generous.

Re: Against SQL

#133

Post by ako »

b33j0r wrote: post #77
slx26 wrote: post #67

I think the problem of this essay is that it's overly technical: only those versed well enough in SQL will really care to read the whole thing, and if they are already at that level, either they accepted that "SQL will get the job done in the end", or they learned to live along it and now even kinda embrace it, and are happy to write about how the examples are very poor and dismiss the critique based on that, when th…

To me, SQL looks like something I should be using 79-char punchcards for. Scalable databases are just so difficult that we’re still driving a ‘64 IMPALA Most of this opinion comes from “SQL” being vendor-specific. Is JSON vendor-specific? Is anything else, that we actually use by choice? Mad at you too, Graph DBs, for sending us on another snipe hunt by adding vendor-imposed innovations, because it makes the enterpri…

You're mixing up different things that don't nescessarily need to be addressed at the same time. SQL is the declarative programming language used to express what data you need.

What type of database engine is used to execute that query is independent of the language. It could be highly scalable or it could be focussed on single user, single process.

What is the problem that needs solving?

Re: Against SQL

#134

Post by randomdata »

DeusExMachina wrote: post #104
endymi0n wrote: post #99

Earlier quoted context omitted.

SQL is exactly like the QWERTY layout: A first quickshot with little design thoughts and unfixable architectural issues that‘s so widespread that everyone is used to it by now. Trying to change to the Dvorak layout taught me a lot about enacting change on such a grand scale. After a lot of hassle switching machines and OSes, typing on other user‘s computers, them typing on mine and general headaches among internation…

While I agree with your point, I wonder why that does not seem to be the case with programming languages. For example, in iOS development (and, more in general, on Apple platforms), there has been a huge shift from Objective-C to Swift. The same arguments should apply there. Swift is much better, but Objective-C got the work done, and many codebases were written in it, especially at Apple. And yet, the whole communit…

There was a strong push for "NoSQL" about a decade ago, but it got marred by document databases trying to usurp relational databases around the same time. When people realized they chose the wrong tool for the job (that is, the document database), they were happy to return to their relational databases using SQL. That completely killed any momentum that had been built to replace SQL with different languages.

Re: Against SQL

#135

Post by rswail »

Annatar wrote: post #124

This web site is amazing: every so often some webshit dipstick who doesn't grok SQL writes an essay bitching about it (instead of learning it!) and it ends up here. Enough with the bitching against SQL and promoting JSON webshit already! If you can't grok SQL, you should consider a career completely unrelated to computers! What the hell has this industry come down to!

Downvoted for the personal attack on the author, but in a spirit of using this as a learning opportunity...

The writer obviously groks SQL. SQL as a language expressing relational algebra sucks. It was a way of trying to make relational algebra "grokable" by end users, in the same way that COBOL was a way to make "programming" grokable by end users.

The author's point is nothing to do with JSON, it's about having a column type that contains structured data.

In "pure" SQL you have to extract that structured data into another table or a hack like "subtables" or something.

The "natural" form of a lot of data these days is JSON. Having a JSON data type is only the start of being able to query it cleanly in SQL.

For SQL to cleanly support JSON, it needs the ability to handle the lack of data types in JSON, and the fact that each JSON element can be an untagged union of potential types.

Re: Against SQL

#136

Post by LeonB »

I would like a typescript style transpiler tool chain for testing out new language features that are seamlessly transpiled down to existing sql.

Once that’s in place I don’t know which features I’d want first… but there’s a lot of them!

Re: Against SQL

#137

Post by zabzonk »

james_woods wrote: post #41

SQL was not made for programmers alone. It has been invented also for not so technical people so that verboseness and overhead is part of the deal. > When Ray and I were designing Sequel in 1974, we thought that the predominant use of the language would be for ad-hoc queries by planners and other professionals whose domain of expertise was not primarily data- base management. We wanted the language to be simple enoug…

> We wanted the language to be simple enough that ordinary people could ‘‘walk up and use it’’ with a minimum of training.

In that case it has been an abject failure. I have been using SQL since the mid 1980s (so pretty much since the start of its widespread adoption) and I have never met "ordinary people" (by which I assume intelligent business-oriented professionals) who could (or wanted to) cope with it.

I like it, but the idea of sets does not come naturally to most people (me included). But I once worked with a programmer who had never been exposed to SQL - I leant him an introductory book on it and he came in the next day and said "Oh, of course, it's all sets, isn't it?" and then went on to write some of the most fiendish queries I have ever seen.

Re: Against SQL

#138

Post by rswail »

pjmlp wrote: post #45
roenxi wrote: post #20

One of the elephants in the room with SQL is that it is one of a small number of popular languages that doesn't use function(arg, arg, arg) It is strange that "SELECT a, b, c FROM schema.table" keeps any aura of respectability. That is legitimately outdated syntax, people don't write languages that way any more. It was a 70s era experiment and what was learned from that experiment is that the style has no upside and…

Here is your function(arg, arg, arg) CREATE [OR REPLACE] FUNCTION function_name (arg, arg, arg) RETURN return_type IS --- END; Then SELECT function_name (arg, arg, arg...) FROM dual; SELECT columns FROM xpt where xpt.id = function_name (arg, arg, arg...); IF function_name (arg, arg, arg...) = ... THEN ...

well, except "FROM dual" is an Oracle-ism because they require a FROM in a SELECT.
Post reply on HN