🔥 The DB Grill 🔥

Ah, another dispatch from the front lines of industry, where the wheel is not only reinvented, but proudly unveiled as a heptagon. It seems Oracle has finally, in the year of our Lord 2026, managed to implement a fraction of the SQL-92 standard. One must applaud the sheer velocity of this innovation. I can only assume the working group is communicating via carrier pigeon.

The premise is that we can now enforce business rules in the database using assertions, thereby placing the burden on ACID's 'C' instead of its 'I'. A noble goal, to be sure. It's a concept we've understood for, oh, about thirty years. Let's see how our plucky practitioners have managed to manifest this ancient wisdom.

They begin by creating a simple table, and then, with bated breath, attempt to write a perfectly reasonable assertion using a GROUP BY and a HAVING COUNT. This is, of course, the most direct, logical, and mathematically sound way to express the constraint: "for every shift, the count of on-call doctors must not be less than one."

And what is the result of this bold foray into declarative integrity?

ORA-08661: Aggregates are not supported.

Perfection. One simply has to marvel at the audacity. They've implemented 'assertions' that cannot handle the most fundamental of assertions: an aggregate. COUNT() is apparently a bridge too far, a piece of computational esoterica beyond the ken of this new "AI Database". What, precisely, is the 'AI' doing? Counting the licensing fees?

But fear not! Our intrepid blogger offers a "more creative way" to express this. I always shudder when an engineer uses the word 'creative'. It's typically a prelude to a gross violation of first principles. And this... this is a masterpiece of the form. A tortured, nested NOT EXISTS monstrosity that reads like a logic problem written by a first-year undergraduate after a particularly long night.

“There must not exist any doctor who belongs to a shift that has no on-call doctor”

This is what passes for elegance? This is their substitute for a simple HAVING COUNT(...) < 1? Codd must be spinning in his grave. The principle of Integrity Independence, Rule 10, was meant to free the application programmer from such Byzantine contortions! The database is supposed to be intelligent enough to manage its own integrity without the user having to perform logical gymnastics. Clearly, they've never read his seminal work, A Relational Model of Data for Large Shared Data Banks. It's only fifty-odd years old; perhaps it hasn't been indexed by their search engine yet.

And the mechanism behind this grand illusion? An "internal change tracking table" that is, by the author's own gleeful admission, a thinly veiled reimplementation of materialized view logs from 1992. Bravissimo! It only took them thirty-four years to rediscover their own work and present it as progress. They've built this entire baroque locking and tracking mechanism—this proprietary enq: AN lock, these ORA$SA$TE_ tables—all to circumvent a problem that has a known, elegant, and mathematically proven solution: Serializable Isolation.

Let's be clear. This entire Rube Goldberg machine exists because their implementation of Isolation, the 'I' in ACID, is so profoundly inadequate. Instead of providing true serializability to prevent write-skew, they've bolted a complex, opaque, and incomplete feature onto the side of the engine. It's a classic case of treating the symptoms because the disease—a weak isolation model—is too difficult to cure. Clearly they've never read Stonebraker's seminal work on concurrency control, or they'd understand they're just building a poor man's version of predicate locking. It's as if they read Brewer's CAP Theorem and decided that 'Consistency' was something you could just approximate with enough temporary tables and proprietary lock modes.

So here we are, with a list of "three solutions":

• The correct, theoretically sound one (Serializable isolation), which is noted with a casual aside, "not available in Oracle Database".
• The application-level hack (explicit locking), which pushes consistency logic out of the database, where it has no business being.
• And now, this new, "pragmatic" solution: a partially implemented, thirty-year-old standard that can't perform a basic COUNT.

It's... endearing, in a way. Like watching a toddler attempt to build a load-bearing wall out of LEGOs. You've tried so very hard, and you've certainly built something. Keep at it. Perhaps in another thirty years, you'll discover SUM(). We in academia will be waiting. Now, if you'll excuse me, I have actual research to attend to.