Arguably not a single statement that you have made in your overly hasty post is true.
You can tell from the post times that I spent over an hour (off & on while doing other work) on my post. This article was so absurd that I wanted to make sure I addressed it exactly the way I wanted to (which I did).
Baker was an established and respected computer scientist and iconoclast.
Therefore, everything he ever wrote or said must be true, according to you.
To treat the letter as if it were written yesterday is foolish and disrespectful
No letter that begins with "I had great difficulty in controlling my mirth..." deserves respect. He was begging for rebuttal. I simply complied.
"Flat files" were used often for batch processing.
See there's one of the many differences between sitting in an ivory tower and actually being on the ground doing the work. This was written in 1991, not 1961. Batch processing had long been surpassed by on-line transaction processing. CICS had taken over for batch COBOL, and mini-computers and PCs were always on-line oriented. Dismissing an entire technology because it performed less well in one area of 5% of your processing sounds like something said by someone who doesn't have to do the work and doesn't have a clue how things really work.
Baker was always in demand. No need to compare resumes: you likely would not rank well against him,
My work is my resume. AFAIC, the only thing that matters is delivering results to customers. If I have relational database technology in my back pocket and my competitor doesn't, I'll kick his ass every time. (This is not a judgement on anyone's ability; it's an assessment of the technology under discussion.)
Today network-style databases remain faster by at least an order of magnitude (and sometimes two) than relational databases.
What difference does it make if you lose data integrity? This commonly happens in flat file environments. Doing the wrong thing faster is meaningless. There are many times when RDMS makes much more sense.
My memories are that Oracle's early versions were performance dogs by any standard.
Oracle was a dog. Therefore relational database technology performed a task that didn't need doing. Just like the internet performs a task that doesn't need doing because ie6 is a dog. Right.
PICK was not a relational database. TOTAL was not a relational database.
Let's see. Both had columns, rows, joins, indexes, stored procedures, and triggers. What else did they need, certification by Codd himself?
Your remarks remind me of how so often when an excellent programmer leaves a shop,
Based on OP's original article (the data at hand), he most certainly would not make an excellent programmer in any shop I've ever been in. He sounds like the ivory tower guru who pontificates B.S. while the rest of us got all the work done. Again, the difference between theory and practice.
Arguably not a single statement that you have made in your overly hasty second post is true:
This article was so absurd that I wanted to make sure I addressed it exactly the way I wanted to (which I did).
The letter was on-point at the time: the ACM believed it to be relevant.
He was begging for rebuttal. I simply complied.
You're 18 years too late! May as well rebuff Isaac Newton for missing relativity!
What difference does it make if you lose data integrity?
The common network-style (CODASYL) and hierarchical databases enforce referential integrity and are full ACID.
Both[ed. PICK,TOTAL] had columns, rows, joins, indexes, stored procedures, and triggers.
Indexes, stored procedures and triggers are implementation details and are not part of relational database theory per se. None are required for a database to be relational: none guarantee that a database is relational. And to be pedantic, neither are "rows" and "columns" part of relational theory: the proper nomenclature is "tuple" and "attribute".
You can tell from the post times that I spent over an hour (off & on while doing other work) on my post. This article was so absurd that I wanted to make sure I addressed it exactly the way I wanted to (which I did).
Baker was an established and respected computer scientist and iconoclast.
Therefore, everything he ever wrote or said must be true, according to you.
To treat the letter as if it were written yesterday is foolish and disrespectful
No letter that begins with "I had great difficulty in controlling my mirth..." deserves respect. He was begging for rebuttal. I simply complied.
"Flat files" were used often for batch processing.
See there's one of the many differences between sitting in an ivory tower and actually being on the ground doing the work. This was written in 1991, not 1961. Batch processing had long been surpassed by on-line transaction processing. CICS had taken over for batch COBOL, and mini-computers and PCs were always on-line oriented. Dismissing an entire technology because it performed less well in one area of 5% of your processing sounds like something said by someone who doesn't have to do the work and doesn't have a clue how things really work.
Baker was always in demand. No need to compare resumes: you likely would not rank well against him,
My work is my resume. AFAIC, the only thing that matters is delivering results to customers. If I have relational database technology in my back pocket and my competitor doesn't, I'll kick his ass every time. (This is not a judgement on anyone's ability; it's an assessment of the technology under discussion.)
Today network-style databases remain faster by at least an order of magnitude (and sometimes two) than relational databases.
What difference does it make if you lose data integrity? This commonly happens in flat file environments. Doing the wrong thing faster is meaningless. There are many times when RDMS makes much more sense.
My memories are that Oracle's early versions were performance dogs by any standard.
Oracle was a dog. Therefore relational database technology performed a task that didn't need doing. Just like the internet performs a task that doesn't need doing because ie6 is a dog. Right.
PICK was not a relational database. TOTAL was not a relational database.
Let's see. Both had columns, rows, joins, indexes, stored procedures, and triggers. What else did they need, certification by Codd himself?
Your remarks remind me of how so often when an excellent programmer leaves a shop,
Based on OP's original article (the data at hand), he most certainly would not make an excellent programmer in any shop I've ever been in. He sounds like the ivory tower guru who pontificates B.S. while the rest of us got all the work done. Again, the difference between theory and practice.