The core idea(s) of DBMS2
My introduction of the DBMS2 concept in an August Computerworld column has excited some heated discussion, little of it focused on what I regard as the core issues. But I must concede that in a short series of monthly 750 word columns (two published so far), with a target audience of senior IT managers, I have not necessarily made a clear statement of whether or why database designers should agree or care.
So here’s a little more of that story.
1. Everybody knows that large enterprises do not have single enterprise-wide data models, nor do they have single integrated enterprise databases, managed by a single DBMS.
2. The situation described in Point #1 is inevitable. Deal with it. Stop your futile efforts to change it.
3. What’s more, the obvious disadvantages to the situation in Point #1 are outweighed by other strong TCO advantages. Different kinds of data models, and different kinds of DBMS (or DBMS-substitutes) are appropriate for different applications and data sets.
That’s it.
Some supporting arguments may be found in my column appearing today (see other post). Most of the ones I had room for boil down to this:
Relational databases are ideally suited to manage facts. Most interesting new applications don’t deal (primarily) with the management of facts.
Comments
2 Responses to “The core idea(s) of DBMS2”
Leave a Reply
Curt,
None of the 3 topics you mention show me any reason why a RDBMS is not valid.
1. Organizations don’t have enterprise data models. So what? I live with it every day. Doesn’t stop me in any way from designing and implementing relational databases to support business needs. This point really makes no sense.
2. See above.
3. TCO? Where is the TCO for your, as yet, undefined, undeveloped, non-existant RDBMS2? Why would another application of database technology be cheaper to implement than relational technology? Again, this point makes no sense.
So, I see three points, but not one of them shows the reader why they should look at an alternative to relational technology. Could you explain in more detail? I’m sure there must be a valid point somewhere, I’m just not seeing it.
Warren
Hi, Warren.
There’s a clear TCO argument for data warehouse appliances, as opposed to centralized RDBMS. There’s a clear TCO argument for non-relational architectures when managing text, security data, etc. Those are examples of the TCO argument AGAINST getting too carried away with relational data integration.
I suspect from your comments that you’re a pragmatist. Good for you. Some of my more strident arguments are directed at the idealists — i.e., Chris Date and his disciples, who seem to argue that (almost) all comments based on experience with, or the capabilities of, relational DBMS are invalid, because commercial DBMS aren’t REALLY relational, and their double-secret TransRelational(TM) DBMS will change everything, automagically making a lot of programming and data administration tasks go away.
Please see some of what are, at this writing, my most recent blog posts, especially the one dated 10/13.
Thanks,
CAM