🔥 The DB Grill 🔥

Ah, yes. I've had the misfortune of perusing yet another dispatch from the digital frontier, a place where the hard-won lessons of computer science are not so much built upon as they are cheerfully ignored. This… tutorial… on combining an "Object-Relational Mapper" with a non-relational document store is a veritable masterclass in how not to engineer a data layer. It seems my students are not the only ones who find the primary literature to be, shall we say, optional.

Allow me to illuminate, for the sake of posterity, the myriad ways in which this approach is a solution in search of a problem, invented by people who find relational algebra too taxing.

• First, we are introduced to the "Object Document Mapper," a term so deliciously redundant it must have been conceived in a marketing department. The entire point of an ORM was to bridge the impedance mismatch between the relational world of tables and the object-oriented world of application code. Using a similar tool to map object-like documents to… well, other objects… is like translating Shakespeare into modern English and calling yourself a linguist. It’s a layer of abstraction that solves a non-existent problem while proudly introducing its own unique failure modes.

• The authors celebrate that "real-world MongoDB applications are schema-driven" by defining a schema… in the application layer. Astonishing. They've reinvented the wheel, only this time it's square and on fire. The entire purpose of a Database Management System, a concept Codd laid out with painstaking clarity, is for the database to be the arbiter of data integrity. Shunting this fundamental responsibility to the application layer is a flagrant violation of the Information Rule. It's not a feature; it's an abdication of duty. Clearly, they've never read Stonebraker's seminal work on the virtues of pushing logic closer to the data, not further away.

• Then there is the transactional theatre. We are told that this contraption "relies on MongoDB sessions and transactional behavior," which, pray tell, are only available on a replica set. So, to achieve a pale imitation of the "A" and "I" in ACID—properties that have been table stakes for serious databases for half a century—one must engage in the ceremony of initializing a distributed system. For a single node! It's the database equivalent of buying a 747 to drive to the local grocery store. You've incurred all the operational complexity for none of the actual benefits.

• And the justification for all this?

  This preserves data locality, eliminates ORM overhead and migration scripts, and increases development velocity. One must assume this is satire. It "eliminates ORM overhead" by... introducing an ORM. It "eliminates migration scripts" by... creating a schema.prisma file that serves the exact same purpose and must be kept in sync. And it "increases development velocity" in the same way that removing the brakes from your car makes it go faster. A triumph of short-term convenience over long-term stability and correctness.

• Finally, this entire exercise is a beautiful, if tragic, misunderstanding of the CAP theorem. They've opted for a system that, in a single-node configuration, offers neither the "A" for Availability nor the "P" for Partition tolerance, all while forcing the developer to jump through hoops to gain a weak semblance of the "C" for Consistency that a proper relational database would have provided out of the box. They've managed to achieve the worst of all possible worlds. Bravo.

One is forced to conclude that the industry is no longer building on the shoulders of giants, but rather, dancing on their graves. Now, if you'll excuse me, I have a relational calculus lecture to prepare. At least someone still cares about first principles.