
What I’m Telling Business People About Why Relational Databases Are So Bad - mpweiher
https://codeburst.io/what-im-telling-business-people-about-why-relational-databases-are-so-bad-6f38d3d6c995
======
btown
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...](https://codeburst.io/doing-without-databases-in-
the-21st-century-6e25cf495373)

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.

------
chmaynard
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.

------
kungtotte
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.

~~~
vineetr
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.

------
rgbrenner
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...](https://codeburst.io/doing-without-databases-in-
the-21st-century-6e25cf495373)

I think he should rename his book _Creating IT Disasters_

~~~
rurban
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.

------
banku_brougham
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.

------
cnewey
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.

------
sixhobbits
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?

------
borplk
One of the worst articles I have ever seen.

------
dragonwriter
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.

------
davidgould
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?"

