Apologies for not being able to add this as a comment in the place where it really should appear.
But the following constitutes a personal attack on me, and I invoke my right to respond.
Though I agree with you in practice, I disagree with you in spirit, I think you're the one who's been brainwashed to believe that set-based is the only way (maybe I'm putting words in your mouth).
FWIW, I have most certainly NOT been "brainwashed" into what you might probably call "the relational religious belief". Brainwashing is when some tutor says something, and the student blindly and brainlessly accepts that as the sole truth without any form of critical thinking. In fact, I have even never been taught the relational model. In fact, I have had to discover all that all by myself. It is a recorded matter of fact that I have expressed severe criticisms toward Date's opinions on the subject of view updating. (correction : "was" a matter of recorded fact. The page seems to have been removed from the site where it was published. Probably has everything to do with the fact that Date has indeed abandoned the view updating position I criticized.)
So I think I have every reason to say that any claim that I ever let myself be brainwashed, is outright propostrous. You are free to think as you please, but if you publicly express any gratuitous and based-upon-nothing personal opinions, I hope you are also enough of a grown-up to see them rebutted by facts and admit it.
The reason why hierarchical and network models have been superseded by the RM has been amply documented in entire libraries full of books on the subject. I invite you to inspect those carefully.
As for "key-value is taking over the market": you are completely free to take "the market's most common opinion" (that is: the mediocre majority of too-lazy-to-think-for-themselves fools who are quite happy to let themselves (and their opinions) be led by the Ellisons and Gateses and Jobses of this world) as the main yardstick for what is valuable and what is not. I personally find that a foolish thing to do, but that's only my personal opinion. I copy-paste here some observations made by someone who faces the horrors of EAV and Key-value almost every day of his professional life :
I work on an application that uses the following "EAV model" (at least, the "EAV model" as I understand it) for many, but not all, logical tables:
R1 {EAV_RELVAR_NAME*, ... }
R2 {EAV_RELVAR_NAME*, ATTRIBUTE_NUMBER*, COLUMN_NAME, DATA_TYPE, ...}
R3 {EAV_RELVAR_NAME, ATTRIBUTE1, ATTRIBUTE2, ATTRIBUTE3, ..., ATTRIBUTE50}
In which one might see the following values:
R1 { {'STATE_CODES'} }
R2 { {'STATE_CODES', 1, 'STATE_NAME', 'CHAR(30)'} ,
{'STATE_CODES', 2, 'STATE_CODE', 'CHAR(2)' } ...}
R3 { {'STATE_CODES', 'ALABAMA', 'AL'} ,
{'STATE_CODES', 'ALASKA', 'AK'} ...}
Basically, "EAV relvars" are created/altered/dropped with inserts/updates/deletes into R1 and R2 (as compared to DDL). This is a trimmed down version of our overall model: there are additional columns in R1 and R2 to specify eav-primary-keys, eav-foreign-keys, business rules, etc... all enforced by procedural code embedded in the "one true front end" of the model.
This morning, I was privy to a 20+ man-hour ordeal that resulted when System A thought CODE_XYZ would be in ATTRIBUTE2, but System B actually defined it into ATTRIBUTE3... I had to laugh at the fact that I was half-listening to the conversation, and half-reading this group's discourse on EAV.
Last month, I got to put in an emergency update (16 man-hours plus "bad marks" for the application) to change ATTRIBUTE16 from 'MAY 2010' to 'MAY-2010' for 430 user-entered data points.
About 5-10% of our code releases are accompanied with "Monday-morning runtime-error cleanups", because EAV_RELVARs were not coded into R1 or R2 identically in production as was done in test/development (both application code and DDL is migrated with strict-versioning software control... our EAV model is not tied down to such bureaucracy as it "allows" developers to set up their EAVs autonomously in dev, test, and prod.).
Last year, I spent a solid 3 weeks tuning replication software exclusively to deal with the lack of a primary key on R3.
I once had to apologize for the inability to put an index on ATTRIBUTE4 of EAV_RELVAR_NAME_x, as it was messing up the performance of a different program that used EAV_RELVAR_NAME_z.
Two years ago, after several years of sinking hundreds of hours perpetually tuning complex queries which needed to join to R3, I finally spent 3 months splitting R3 into hundreds of physical partitions (one per EAV_RELVAR_NAME), in order to give the DBMS optimizer the stats needed to see that there were, e.g., 50 'STATE_CODES' and 200,000 'LOCATION_CODES'. I was congratulated for the ingenious solution, though the irony was missed on everybody when I pointed out that, with this change, there would be a new policy whereby adding a new EAV_RELVAR_NAME would entail running a script which added an associated partition to R3 (yes, with DDL).
My clients want a new front end for loading data into R3 for one of their EAV_RELVAR_NAMEs (while enforcing all appropriate constraints and security), and they want to know why it will take 4 months to build.
I often point out that I could rewrite the entire EAV system in a fashion that was superior in every way, using the dynamic-DDL against data dictionary instead of DML against R1 and R2, but I'm always informed that we're "committed" to this approach (there was a 7-figure up-front expenditure to build it, and we'd have to rewrite 98% of our codebase to switch to stand-alone tables), and that the ends don't justify the means.
If you really believe that such scenarios are an improvement over the RM, then by all means go ahead. Don't blame me for how much it hurts when you finally bang your head into the wall.
