What I’m Telling Business People About Why Relational Databases Are So Bad
codeburst.io
codeburst.io
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.
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.
To extend his argument, browsers are responsible for XSS.
I think he should rename his book Creating IT Disasters
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.
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.
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?
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.
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?"