Against SQL • Hacker News Board

Re: Against SQL

#331

Post by Annatar » Sun, Jul 11, 2021, 8:49 AM UTC

rswail wrote: post #135

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

"Downvoted for the personal attack on the author"...

Yes, well, I've had it with charlatans in this industry; in every other profession, professionals take on responsibility for their actions, just in information technology and computer industry, almost everybody hacks, builds crap and takes responsibility for nothing. "We never point fingers at people, just at technology..." Yeah well guess what, that technology was "invented" by people, usually one person. When there is personal responsibility in the game, maybe the people responsible will stop reinventing the wheel and start producing small, fast, simple, high quality software...

If you spout nonsense, I will call you out personally for it, as I do not suffer fools, since my patience has worn out: enough with the kindergarten for adults already, that has to stop as well! Take responsibility for what you spout, bear the consequences. Enough with crap technology and constantly reinventing the wheel!

There is no need for JSON in the first place: a flat UNIX text file, delimited by colons or pipes and streamed as an input to another filter or the final program does just fine. So the premise that it has to be JSON is already broken, and anyone who doesn't even question that premise has already missed the elephant in the room. Ergo, if the author is even considering solving the problem so that it would fit into JSON, then the author lacks insight, and if he or she lack insight, then they are not equipped to solve the problem, which in the end, quite unsurprisingly, they do not solve.

Why am I so much against JSON? Because not only is the format ill thought out, but constructing a reliable, robust parser for it is a technological nightmare. How then is this a better solution? How is it a more robust one? How is it a simpler one? The answer to all three questions is quite obvious, at least to me: it is none of those things.

If somebody who is supposed to be a professional with that level of insight completely misses or accepts that JSON isn't simple, that it isn't robust, and that therefore it is not the better solution which does not better the industry and computer science as a whole, then that person has no business writing, let alone designing anybody's software.

Re: Against SQL

#332

Post by Annatar » Sun, Jul 11, 2021, 8:51 AM UTC

chakkepolja wrote: post #249

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!

If anything, he is complete opposite of webshit.

Which is why he uses and advocates for JSON, right? That is so horribly wrong on so many levels, as JSON is an incomplete[1] and completely unnecessary reinvention of a wheel, just because the dispstick who invented it didn't understand that the problem could be solved with flat UNIX, plain ASCII files. "Wait, what is this UNIX thing, is that something to eat...?"

Like Paul Graham wrote, "So it's easy to launch a devastating attack on a new idea, and anyone who does will seem clever to those who don't understand this asymmetry."[2]

While SQL is by no means a new idea, it was easy to shit on E. F. Codd's work, but I don't see a better solution proposed by the author of that essay!

To the salt mines with the lot, for such people have no business touching programming!

--

[1] Parsing JSON is a minefield: http://seriot.ch/parsing_json.php

[2] http://paulgraham.com/newideas.html

Re: Against SQL

#333

Post by bmn__ » Sun, Jul 11, 2021, 9:32 AM UTC

fnord77 wrote: post #74

pjungwir wrote: post #10

It would be really cool if databases had an Option type. Then you could remove all the NULLs. Although you can mark a column as NOT NULL, that restriction doesn't "travel": it isn't present for function inputs/outputs, subquery results, etc. Adding it to the type system gives you a lot more mileage. And then joins could be option-aware: an inner join would have outputs matching the input types, but an outer join woul…

you can use COALESCE to remove nulls

Explanation for your downvotes: you misunderstood GP's post, he refers to removing the concept of null as it is currently specified from the language, not removing null values from data.

Re: Against SQL

#334

Post by smackeyacky » Sun, Jul 11, 2021, 9:48 AM UTC

spicybright wrote: post #182

barrkel wrote: post #121

Earlier quoted context omitted.

I think I'm experienced enough to understand the article, and I agree. I've written multiple optimizing SQL generators (altering generated SQL to access better plans), and rewritten hundreds of queries for better performance, which involves trying many semantically identical rewrites of the same query. I agree with Jamie. I think SQL is irritatingly non-composable, many operations require gymnastics to express, and I…

What is your opinion on abstractions on top of SQL queries? On paper, a more expressive language that spits out SQL queries sounds great, but I've never seen a single one not become a pain in the ass to use.

EnntityFramework in .NET core is actually very good for an ORM that allows you to get right into the weeds of your queries if you need to. LINQ was ok, but entityframework is a lot better, no rubbish gui layout and the relationships are explicit and can be specified through object annotations right down to the level of controlling the table column collation.

If you have bounced disappointingly off ORMs like I have since the 1990s, EntityFramework is a great step forward.

Re: Against SQL

#335

Post by jhgb » Sun, Jul 11, 2021, 11:12 AM UTC

mcv wrote: post #277

goto11 wrote: post #111

Earlier quoted context omitted.

SQL is often conflated with the relational model (hence the term NoSQL for non-relational databases), but the article is careful to explain that the relational model is great, but SQL is a clunky syntax/standard. Going to graph databases is certainly throwing the baby out with the bathwater. The relational model was invented to address shortcomings in the hierarchical and graph database models.

Do graph databases predate relational databases? Do you have a source for that? I thought graph databases were a fairly new thing. I only recently started working with a graph database (a bit over two years now), and it struck me just how terrible relational databases are at relationships, compared to graph databases. I know nothing about the history of databases, but my impression is that relational DBs are basicall…

> Do graph databases predate relational databases? Do you have a source for that? I thought graph databases were a fairly new thing.

I believe they just called them "network databases" back then.

Re: Against SQL

#336

Post by blacktriangle » Sun, Jul 11, 2021, 1:33 PM UTC

balfirevic wrote: post #324

blacktriangle wrote: post #262

Earlier quoted context omitted.

NoSQL is much bigger than Mongo, which deservers books written on hating it. The relational algebra is great, but its also overkill for things like event streams, message brokers, caches, does hit scalability issues for certain legitimately large workloads, and in comparison to Mongo and other document-based databases, fails when your data simply is not relational. Then there's the whole object/relational impedance m…

> fails when your data simply is not relational What's an example of data that's not relational?

One case is where you have fairly ragged entities that may have several of many attributes but result in very sparse rows.

Another case is when users are effectively designing their own schemas but you want to keep them, for example I have a database for a CMS where users can define nested hierarchies of keys with translations that would be impossible to fit into a schema. You could just toss this data into a JSON column, but its an example of nonrelational data.

Re: Against SQL

#337

Post by nytgop77 » Sun, Jul 11, 2021, 2:14 PM UTC

glogla wrote: post #225

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…

I think most of the criticism is about SQL not being the best programming language - a language in which pros build application, especially web applications. And SQL is truly not best at that. It is not the best API. But in my world, SQL is much more of a Human Data Interface than Application Programming Interface. SQL is used for both ad-hoc and automated data querying and transformation. It is something manufacturi…

Spot on.

Re: Against SQL

#338

Post by no-s » Sun, Jul 11, 2021, 9:43 PM UTC

treis wrote: post #269

ethbr0 wrote: post #212

Earlier quoted context omitted.

SQL abstractions are stuck with a market problem, for reasons in this thread. Everyone who wants better-than-SQL is generally already adept at SQL relational gymnastics. And everyone who isn't adept at SQL wants to be able to ignore relational thinking. End result? Abstractions target the easier of the two markets: people who don't want to learn relational modeling.

I think there's some low hanging fruit out there. Simple improvements to make queries easier to write and maintain. As an example, ActiveRecord allows you to define scopes. If you have an account things like: platinum: -> value >100000 churn_risk: -> churn>.95 You can then chain these together i.e Account.platinum.churn_risk to get all the platinum accounts at risk of churn. Afaik there's nothing similar in SQL. If y…

While I agree it’s a PITA, most SQL-interfaced RDBMS support views, which is a way to abstract the Platinum customer issue you pose into something composable, albeit in SQL terms, not in the dotted property chaining style you propose. In the past I’ve created view generators to automatically populate a sweet syntactic palette for application semantics. Modern query planners are hardly bothered by the implied excess of joins any more, and will often use the embedded literals to optimize the query plan before execution…

I’ve plucked that low hanging fruit before, and it can taste great even in SQL sauce.

Re: Against SQL

#339

Post by jandrewrogers » Mon, Jul 12, 2021, 12:06 AM UTC

mcv wrote: post #320

jandrewrogers wrote: post #297

Earlier quoted context omitted.

Graph databases have been around nearly as long as databases generally, at least since the 1970s. The sole feature that makes a database a "graph database" is support for a minimal amount of recursion in queries, which was a feature before SQL even existed. There are good technical reasons graph databases have never been commercially successful. Most databases support some form of recursion and have for decades. The…

Interesting. But are those old graph databases similar to modern ones like Neo4j? Neo4j has pretty amazing performance compared to doing the same thing in SQL. Although it's certainly possible that SQL database was poorly designed. Even so, a handful of developers new to graph DBs managed to easily beat its performance. I've also heard that some modern graph databases are not true native graph databases below the sur…

You can build almost any kind of database on top of any decent database kernel -- they are similarly expressive. The "kind" of database is just a skin over the kernel. However, different kernel designs make different performance tradeoffs in several dimensions. A graph database is much more join-intensive than a relational database, for example, so it may make sense to reduce select performance to increase join performance.

Graph database technology was essentially stagnant for decades, and the design of Neo4j is from that era. The basic technology is the same across all graph databases, just incrementally modernized and micro-optimized, hence why they all have the same scalability and performance problems. The market gap is that most interesting graph data models have at least 10^12 edges and graph databases stop working well long before you get to that scale.

There was a major breakthrough on this topic around 2008 at a corporate research lab, a new way of representing graph data models that was highly scalable. By coincidence, I was working in graph database R&D at the same time elsewhere and had some exposure to the research, made several material improvements to the new approach, and even built working prototype database based on it that addressed a lot of classic scalability and performance issues. I stopped working in graph databases shortly thereafter but to this day have not seen a single implementation in the wild based on that research. It isn't the kind of thing you can build on top of an existing database kernel, the internals were necessarily pretty exotic, which is part of the problem.

tl;dr: Graph databases have been stuck in the same local architectural minima for half a century, receiving a fresh coat of paint every decade or so but not addressing any of the reasons almost no one can use them.

Re: Against SQL

#340

Post by aliasEli » Mon, Jul 12, 2021, 7:59 AM UTC

ris wrote: post #192

masklinn wrote: post #171

Earlier quoted context omitted.

> I wonder how much of the limitation are necessary in order for the query optimizer to have any chance at finding a good execution plan. Probably in exactly the opposite way: the limitations of SQL put a lot of work on the back of the query optimiser without allowing for said optimiser to easily reason about the queries, or for the writer to easily feed the optimiser (short of dedicated extensions e.g. Oracle's opti…

I think it's important to distinguish between what's highly optimizable in theory and what's easily optimizable in practise . The latter working here and now, and the latter being a (possibly perpetual) decade of compiler development away. An example here is how, sure, in theory, JITs can outpace AOT compilation because they have all the information the AOT compiler has plus runtime insights. But the ability to truly…

> An example here is how, sure, in theory, JITs can outpace AOT compilation because they have all the information the AOT compiler has plus runtime insights. But the ability to truly do that always seems to be a decade of compiler development away, with many giving up on the idea entirely.

JIT has been used very successfully for a couple of languages, e.g. Java. But adding it requires a lot of effort. The same thing is unfortunately true for new query languages, building a new database is really expensive, this is probably the main reason that there have been no serious alternatives to SQL.