Sure, object-relational impedance mismatch is a problem, but if you're going to throw the baby out with the bathwater, you need to propose alternatives. Luckily for us, this is not the author's only post...

The author's followup article advocates instead for building your own in-process persistence system for each application, with no persistent data structure other than a (non-write-ahead) log, even for an application the size and scale of Stack Overflow itself: https://codeburst.io/doing-without-databases-in-the-21st-cen...

I post this only because "name 20 things wrong with this article" might be a good take-home exercise for a student, or as a weeding exercise for recruiting... except that, on the off chance the student/candidate were to fail at said exercise and buy into the content unironically, I would have caused irreparable and irresponsible harm to their learning process, their future businesses, and the safety of their customers' data.

Seriously, what we have here is a fundamental misunderstanding of ACID, of the very idea that a computer might crash at an arbitrary point in a program, of the general importance of distributed systems, of safe software deployment, of parallelism, and of the very idea that a schema might evolve over time. It saddens me to know that this type of advice exists and receives a platform.

When I was working in and around the IBM ecosystem during the '80s and '90s, I often ran across pundits like Lance Gutteridge who made a nice living as self-proclaimed experts at something or other. They wrote trendy books and gave expensive presentations to corporate insiders. They usually turned out to be a flash in the pan.

That's a whole bunch of words to say you just don't plain like relational databases.

Using SQL injection as a case against them is also fairly silly; the error there is that you don't sanitise your input. It has nothing to do where the query goes, any type of data store is vulnerable in that scenario.

SQL injection falls into a general class of vulnerabilities where user input escapes the data plane and get injected into the control plane. I was looking for the article to provide insight on how a new database or query+execution language would avoid this entire class of vulnerabilities, because that is what I would expect as a solution. So yeah, picking on RDBMS for SQL injection is fairly silly, and worse, it betrays ignorance on the subject.

To extend his argument, browsers are responsible for XSS.

The author wrote a follow up about how he thinks you should build things without using a relational database: https://codeburst.io/doing-without-databases-in-the-21st-cen...

I think he should rename his book Creating IT Disasters

Exactly. He only knows about the advantages of persistence layers, i.e. serializing objects. But he doesn't talk about the problems of serializing pointers (refs), or even graphs (pointers upwards or to siblings).

A relational structure avoids that, and so you avoid this mess. A OO store or Graph DB can handle that but is an order of magnitude slower because it has to serialize pointers, usually by checking against internal hashes or converting to arrays. Such a store is very nice to use for noobs, but once you understand the complexity of writing to such a store, you happily fall back to design a simpler scheme, which is optimized for fast reading and writing.

What he describes there amounts to a naive, lobotomized form of event sourcing.

As I read this I began accumulating comments to make on various points, but eventually realized that this author isn’t the expert in enterprise software as claimed.

I don't really know where to start after reading this - it reads like a collection of poorly-informed reasons that the author dislikes relational databases - almost all of which are entirely orthogonal to the concepts of relational algebra or modern database management systems.

For example, SQL injection can hardly be considered a problem with database systems alone - and the problem with using code injection as an example of how RDBMS are "so bad" is that code injection isn't inherent to databases - it's to do with executing unsanitised user input (which is a problem that should be handled in the software accepting user input).

Doing a little bit more digging, it appears that the author is peddling his own technology (the "contextual database") which is presumably the solution all these problems... but the product's website has such a scarcity of technical information that it appears to be almost entirely useless.

Smells like snake oil to me.

The analogies makes sense to me because I understand the fundamental concepts of RDBMS and sql injection. Trying to understand sql injection via telegram STOPs is a really broken analogy that only makes the concept more confusing.

With hindsight to say that ORMs are badly needed for complicated systems doesn't seem as impressive as the author tries to imply. The tone of "I knew this all along and it's stupid that people didn't invent and use ORMs before they did" is not helpful and slightly unpleasant.

His point seems to be "I have learned how to explain some of technology's hard problems in a non-useful way to people who don't understand them, in such a way that they still won't understand them". I assume the author uses this to sell books to people who want a shortcut to understanding these problems. I wonder if he provides any solutions?

One of the worst articles I have ever seen.

As someone who is both familiar with relational theory and has spent most of a couple decades in the trenches with enterprise systems backed by RDBMSs, this seems to be late-night TV commercial levels of misrepresentation; I'm not surprised it comes from an executive of a company selling an alternative (the “contextual” database), but I am surprised it comes from the CTO and not someone whose bailiwick is sales or marketing. Well, maybe not so surprised, I don't think the hyperbolic case it tries to make is particularly intelligible to business decision-makers, and I would expect a skeleton to Target the audience better. It targets a non-technical audience, but it doesn't focus on actual business problems just technical complaints with analogies.

When I see a commercial or article that misrepresents the established alternative to what is being sold this way, what it communicates to me is that the vendor isn't selling something that solves a real problem, so they have to artificially create a perception of a problem as a sales technique rather than drawing honest connections to the real problems experienced by the people to whom they are selling.

When I was a SQL Server database engine developer at Sybase in the early 1990s I had an engineering interview candidate like this. About ten minutes into the interview he started explaining to me that SQL was a fraud, that the world would all be using the much superior PICK system if only Oracle and Ingres and IBM hadn't conspired to force SQL on everyone. He got quite vehement. The highlight for me was the heated assertion that SQL was like communism.

Fortunately he was sticking to the interview schedule and left without becoming abusive. Unfortunately I was so taken aback that I failed to ask the only remaining interview question: "So comrade, why do you want to work with us here in the Kremlin?"