Shortly after submitting my previous column in this series, I received an e-mail from Bill Lewis, one of the visitors at my Database Debunkings Web site. It brought to my attention one of the many examples that validate my arguments so well and demonstrate the fuzzy thinking induced by the object approach and the lack of understanding by many practitioners--particularly the new generation of Java and HTML programmers--of fundamental database concepts and principles. Here's Bill:
"Thought Database Debunkings might find these quotes interesting. They are from a report on Java 2 Enterprise Edition by The Middleware Company. The J2EE platform has much to recommend it as a distributed application platform but, unfortunately, here we go again, casting the database as just some bizarre aberration that programmers occasionally have to deal with. Apologies for my bad attitude."
Bill's apology for the comments he added to the quotes from the source document is unnecessary--I actually left them in (in brackets) because they are very much to the point. It's the source document that requires an apology, but I won't hold my breath. I am expanding on his brief comments and adding some clarifications.
"Data components are much more intuitive to work with than rectangular database rows. It is much more natural to call employee.getPassword()than to deal with a relational result set." [More natural ... for whom?]
Bill is quite correct here, of course, that such calls may be comprehensible to programmers, but certainly not to end-users; and certainly not because the calls are inherently "more natural", but rather because programmers learned specific programming languages that make such calls. Besides, aren't database rows data components? If not, then what are they?
More important, however, it is extremely misleading to generalize from a simple operation to data management as a whole. In fact, the forgotten major objective of relational database technology (which is underlied by set theory) has been to simplify matters by simultaneously enhancing the power of the data language and eliminating large amounts of complex programming. Indeed, in my first book I compare a SQL statement to its programming equivalent to show that even a poor relational implementation with a data language such as SQL tends to do a much simpler and more intuitive job than programming. In my third book I demonstrate how SQL's lack of support of a simple and common relational (set) operation--table comparison--complicates the data language enormously and makes it look like programming. The relational expression is much simpler and more intuitive.
Moreover, many programmers tend to completely ignore those aspects that a DBMS should and could relieve them from, such as integrity enforcement and performance optimization. Once those are taken into consideration, of course, the argument that (application) code is "easier" than relational database management crumbles. (Note very carefully that performance optimization is quite a tall order even for a DBMS on a known and controlled platform, let alone for applications on user clients unknown and uncontrolled by the application programmer!) Indeed, that is precisely one of my main criticisms of XML in the previous article in this series.
"... business process components must operate on rectangular rows, rather than on data components, which is highly non-intuitive." [Guess that's why nobody uses Microsoft's Excel or Access, since these products present data in 'rectangular rows'--as opposed to round rows? Spherical rows?]
I again agree with the thrust of Bill's comment, but some clarifications are in order here too. First, note that the quote refers to operation on data by business process components, while Bill's comment refers to presenting data. These may seem distinct, but essentially they are not. Programmers must present results to users and users of software such as Excel must operate on the data to get the desired results presented.
Second, what makes processing easier--or more intuitive or "natural"--in any circumstance is the organization of the data, the operations to which the organization lends itself, and the syntax of the data language in which the organization and operations are expressed. There is ample evidence to show that there is no way of organizing and operating on data that is superior to the relational way. Reliance on a hierarchical organization is another major source of unnecessary complexity in XML.
"Persistence is the storage of enterprise data in a durable data store, such as a database. Any serious commerce application requires persistence ... [No kidding, really?] [A] persistence service should provide ... the ability to override the server-side platform's persistence engine and provide custom persistence routines if necessary. [Application-based integrity rules, then?] As the database is usually the bottleneck in a commerce deployment, it is desirable to avoid accessing the database whenever possible." [By all means, run away! Run away!]
Attaboy Bill. I rest my case.
About the Author
Fabian Pascal has a national and international reputation as an independent database technology analyst, industry critic, consultant, author and lecturer. For more than 13 years he held various analytical, and management positions in the private and public sectors, was affiliated with Codd & Date, has taught and lectured at the business and academic levels, and advised vendor and user organizations on database technology and implementation. He is co-founder and editor of Database Debunkings, a web site dedicated to dispelling prevailing fallacies and misconceptions in the database industry, with C.J. Date as senior contributor. He has contributed extensively to most trade publications, and his third book, Practical Issues in Database Management--A Guide for the Thinking Practitioner, was recently published by Addison Wesley.
For More Information
