3 ms·
Arguably not a single statement that you have made in your overly hasty post is true. To address a few: Henry Baker is no troll. His letter was written to the
by giardini 17y ago
Arguably not a single statement that you have made in your overly hasty post is true. To address a few:
Henry Baker is no troll. His letter was written to the ACM in 1991. Baker was an established and respected computer scientist and iconoclast. To treat the letter as if it were written yesterday is foolish and disrespectful, In any case, had Baker's remarks been misguided or irrelevant then the ACM would not have published them.
Baker was always in demand. No need to compare resumes: you likely would not rank well against him,
"Flat files" were used often for batch processing. For sequential processing and merging/splitting/sorting of data they are usually faster than RDBMS. During that processing, temporary files might be created that are indexed, hashed, or sequential.
Today network-style databases remain faster by at least an order of magnitude (and sometimes two) than relational databases. Ask any knowledgeable mainframer about the relative speeds of their network-style vs relational databases. The same holds for smaller computers too.
Baker would have no problem "wrapping his head around" almost any problem. An archive of some of his research papers:
http://home.pipeline.com/~hbaker1/ http://home.pipeline.com/~hbaker1/
You saw "subsecond intercontinental response time on massive relational database installations as early as 1981", when IIRC the only relational databases available was Oracle and possibly Ingres. My memories are that Oracle's early versions were performance dogs by any standard. But perhaps you can refresh our memories by citing performance statistics and showing us benchmarks.
PICK was not a relational database.
TOTAL was not a relational database.
Your remarks remind me of how so often when an excellent programmer leaves a shop, the remaining developers diss his work and argue for rewriting all of his (excellent working) code.
But to miss on almost every statement? Oh, my!
- chipsy 17y agoWhat bugs me is that even though Baker states in the comment that he proved a particular deficiency in the relational algebra(the expression of transitive closures), the assertions he uses to lead into this seem extremely vague: they(relational databases) made trivial problems obviously trivial, but did nothing to solve the really hard data processing problems... organizations, budgets, products, etc., are hierarchical; hierarchies require transitive closures for their "explosions"... He never describes concretely what an "explosion" is in a real situation - not in the comment, at least. I'll give the benefit of the doubt that perhaps he brings it up in some paper. But my understanding is that the relational algebra is useful primarily because of its linguistic properties - instead of every problem needing a customized data model and customized graph-traversal solution, it describes how to use a generic query syntax and joins everywhere. While this limits the theoretical power of the system and introduces order-of-magnitude slowdowns, it still solves a major subset of business problems, and it does it with a more compact description than the equivalent graph solution. And that, in turn, means that the theoretical limitations aren't necessarily going to matter for shipping and maintaining a solution, especially when working with a short-term view and small scale. Essentially, he banks on his credentials to turn an "academic" oriented statement into a "industry" one. But from the 70s onward he was writing papers on garbage collection, concurrency and PL theory, not going out and building systems in the industry. So my view is that he's being overly biased towards theoretical purity above practicality, a tendency that has led many an academic astray. (This is not a slam to academics and their pursuit of purity, though. It's a great way to advance the computing arts, and complements well the messy practicality of hackers.)
- chubbard 17y ago> So my view is that he's being overly biased towards theoretical purity above practicality, a tendency that has led many an academic astray. Not so fast. He contrasts working systems in practice compared to the pure relational technology. He is directly saying relational technology was one of purity backed up by mathematics to make it seem more rigorous and battle tested. Where we have a perfectly practical solution that works well and performs better. I don't see his academic purity leading him away from practicality at all. I think his academic resume is making you think he must be all about purity, but in fact he's being very practical.
- edw519 17y agoArguably 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.