Doomed to Repeat it

Like the other Harvard students in the hall, I thought that J. K. Galbraith had whupped Bill Buckley, Arthur Laffer, and others in debating Reagan's tax cuts. (And as now, I was a political conservative!) Why, then, did Galbraith sound so furtive as he argued that the success of JFK's tax cuts was "ancient history"? Watching later on TV, I realized that my one bright spot, Laffer's conclusive reply that 'we are in an institution of learning, isn't the whole point to learn from the past?' was simply the apex of a dominating Buckley victory completely lost on my sophisticated classmates. It comes to mind, again, as I refresh my knowledge of the fundamental database text by C. J. Date ("Codd and Date" until Codd's death). At the beginning of the book are quotes including "those who don't know history are doomed to repeat it." It strikes me that software technologists often dismiss relational technology as 'hopelessly stuck in the 1970's,' much as Galbraith dismissed the JFK tax cuts as "ancient history." Relational technology is a supreme example of learning from history, and as a consequence has stood the test of history. At the end of the 1960's, Codd looked at the file-based, ISAM, and hierarchical storage structures used in computers and saw their limits. He looked at the nascent CODASYL 'network' data model also. Now CODASYL was a huge leap forward. It provided substantial independence from storage location and hardware architectures. But what did Codd see? He saw that the data structures presented in these models were not a benefit to data storage, but were instead a liability. Indexes, hierarchies, and networks all trapped their stored data because of the great difficulties they posed in restructuring and re-presenting it. If you could not phrase your query in terms of the data structure navigation - the index to use, the hierarchy to descend, the network to traverse - you were out of luck. You had to collect huge volumes of data, reconcile it appropriately, and do your own sorts and correlation and aggregation. Sound like fun? I was recently involved in a "post-relational" effort that used a relatively new data modeling mechanism from academia. A long-experienced co-worker was describing his problems with making it work. "Because each object only has single ownership, I have to do all this traversal work just to insert a single row of data. I cannot ever remember encountering a data model like this!" He paused, and I looked straight at him and said, "CODASYL." He nodded, shrugged, and moved on. This "post-relational" model had failed to learn from history. Before you savage relational technology, you really need to understand how horrible were the limitations of pre-relational systems. I don't know if there is an "easy" data management, but once you see what preceded it, you'll see that it's the least difficult. You'll see that complex and extensive data models that are quite hard in relational are impossible and unthinkable under other approaches. Be sure you know this history, or else...