Oh, dear — Chris Date is displeased with me
Chris Date is quite annoyed with me, and has taken issue with various things I’ve written. Some of his reasoning is hard to follow. For example, he said something to the effect that it would be silly for him to ever say anything misleading, because he’d immediately be caught out. Uh, Chris – you’re the guy who’s berating the terrible level of education and understanding in a field for which YOU WROTE THE DEFINITIVE TEXTBOOK (which has sold “over 700,000 copies”). If your readers can’t even understand the correct things you say in your book, why should they be able to instantly spot the errors? Read more
| Categories: Theory and architecture, TransRelational | 26 Comments |
EII marketing soup
In the comments to another thread, the subject of EII (Enterprise Information Integration) came up. It’s a tricky one, for several reasons.
First, it’s a marketing construction — a blend between between ETL (Extract, Transform, Load) and EAI (Enterprise Application Integration). It’s a legitimate category; all those things are getting smushed together as near-real-time apps become more prominent. Still, it’s also an attempt to grab marketing turf.
Second, it’s commonly associated with a marketing overreach — the claim that an EII “platform” or “suite” will do everything a DBMS does (almost), but fully and heterogeneously distributed as well. Yeah, right.
Third, two of the sharpest proponents have been acquired by behemoths that tend to obscure their acquirees marketing pitches — Ascential by IBM and SeeBeyond by Sun.
Fourth, some of the best grand integrated EII suites (at least the ones that started as ETL, which is the side I’m more familiar with) aren’t complete yet. So vendors didn’t want to be too clear for fear of freezing current sales. I’m referring here mainly to Ascential and Informatica. They told analysts of their grand plans, but they haven’t been so eager to openly publicize the full details.
Fifth, the area is getting integrated with development tools for composite applications. Good examples there are SeeBeyond and Intersystems’ Cache’.
Sixth, no EII vendors’ plans fully work unless they have full relational and XML integration, and nobody really has been doing a great job on that, typically being strong in one area or the other.
Obviously, this is an area I have to research actively; EII is the neuromuscular system that holds DBMS2 together. But all the research in the world won’t change the fact that as of now it’s the weak spot in the story. There’s lots of great database management technology, and lots of excellent reasons to use a variety of kinds of that technology in your enterprise. But the tools to knit the resulting heterogeneous databases together are still sadly deficient.
It’s not about a single database
Critics of the DBMS2 idea generally are focused on the design of a single database. That’s somewhat missing the point.
Here are some excerpts and paraphrases from a discussion over on TDAN.
- “DBMS2” is NOT primarily a blueprint for how to design a single database or a single DBMS. That said, it does give guidance as to what kinds of DBMS and data architecture choices you should consider and favor for each cluster of applications.
- Text, presence, authentication, customer profiling – I don’t think any of these will wind up being handled relationally, although at least in the case of customer profiling that’s currently a minority viewpoint.
- In particular, text processing is poised to explode as a fraction of the overall IT burden.
- XML is pretty clearly going to be the basis of text data management.
- Unless all your apps are built by the same company, and perhaps not even then, there’s no way you’ll have a single integrated database. The way your different databases will talk to each other is XML.
- It’s clear that a typical large enterprise’s data structure will evolve to part relational and part XML, and possibly some other data models as well, all tied together by XML. None of the relational-über-alles arguments can or should change that. At best, they are reasons to make the relational piece bigger and more tightly integrated.
| Categories: Database diversity, Theory and architecture | 3 Comments |
Limitations of the Relational Model
In my October Computerworld column, I tried to explain some of the reasons why I don’t think the pure Relational Model should be as absolutely dominant as its most fervent proponents assert.
The key points were:
1. Logical and physical modeling will never be completely separable.
2. “True relational” DBMSs are very unlikely ever to be practically useful, except perhaps in narrow niches.
3. Enterprises don’t fully control their data models.
4. Duplicated data is not inherently bad.
5. Saying that the relational model (RM) is based on mathematics proves almost nothing.
6. IT isn’t just concerned with facts.
For details see the link above.
And while I’m at it, here’s a link to my September Computerworld column, on three life-and-death apps that won’t get built with a relational architecture.
| Categories: Theory and architecture | 30 Comments |
TransRelational(TM) nonsense
Database guru Christopher J. Date is apparently accepting money from attendees to his seminars on TransRelational(TM) database archicture, so that he can tell them about an as-yet unreleased product from Required Technologies, Inc.
This is regrettable on multiple levels.
1. Required Technologies shut down product development in 2002, after running through $30 million; there’s great acrimony between investors and the CEO; and lawsuits are likely.
2. Required’s product never did most of what Date seems to be claiming it now does. It was a read-oriented columnar data store, much like Sybase IQ or a number of other products from younger companies. Read more
| Categories: Benchmarks and POCs, Columnar database management, Memory-centric data management, TransRelational | 65 Comments |
Typical bogosity — the “censorship” furor
Fabian Pascal and Alf Pedersen are complaining endlessly about Computerworld having censored some comments of theirs, in response to blog posts of mine (the first of which was a response to Alf’s blog post in response to my August column). They even seem to have gotten Tom Kyte worked up about it.
So let me be very, very clear.
1. I never had the right or ability to edit or censor comments.
2. I opposed almost all the editing and censoring that did occur.
3. I vehemently opposed the policy of editing comments (mine or anybody else’s) without a posted notice to the effect that they’d been edited, because that amounts to putting words into somebody’s mouth they didn’t actually say. This is the prime reason I no longer blog at Computerworld. (Had Computerworld had a posted warning about the likelihood of editing, as newspapers have on the Letters to the Editor page, I might have felt less vehement. But they have no such notice, or if they do it’s buried out of sight in a long legalistic Terms of Service page somewhere.)
4. I don’t recall ever suggesting the removal or editing of any comment whatsoever, except for one garbled non sequitur that wasn’t in a DBMS2-related thread.
5. I have a pretty good idea of why some posts were censored, based on direct communication with the editor in question, and it had to do with tone and nastiness and promotion of people’s websites, not with the substance of their comments. There’s only a slight chance I’m wrong about that. Indeed, I’m pretty sure he doesn’t have the technological knowledge to understand, for example, the main differences between Pedersen’s opinion and mine.
Let me stress that all this applies only to the blog editor, who’s a very different kind of person from the other editors it has been my pleasure to work with at Computerworld.
| Categories: About this blog | 6 Comments |
The Amazon.com bookstore is a huge, modern OLTP app. So is it relational?
I don’t know for a fact that the Amazon.com bookstore is the world’s biggest OLTP application — but if it isn’t, it’s close.
And the thing is — that’s never been an entirely relational application. Oh, the ordering part surely is. But the inventory lookup is currently driven by an OODBMS (from Progress). The personalization used to be done in Red Brick (I knew which software replaced it, but I’m forgetting at the moment — it may even be one of the relational warehouse appliance vendors). And of course the full-text search is a custom in-house system.
| Categories: Amazon and its cloud, Cache, Data types, Database diversity, Memory-centric data management, Object, OLTP, Progress, Apama, and DataDirect, Specific users | 4 Comments |
Or to put the core idea another way
Break the data management problem into pieces, and stitch the pieces together.
Some of the pieces are best managed relationally, for all the well-known reasons; some, especially but not only the document-oriented ones, are not. XML-based SOA, or a successor, is the right framework for most of the stitching.
| Categories: Database diversity, Theory and architecture | Leave a Comment |
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.
| Categories: Database diversity, Theory and architecture | 2 Comments |
Restarting this blog; comments policy
I was going to let this blog sit idle until I could get around to dressing up its look and feel more. But I don’t want to wait for that, nor take the trouble to do it quickly, so what you see is what you get. Please excuse any dust or exposed girders.
For now, we’ll go with a very simple policy on comments.
1. I reserve the right to delete any comment at any time for any reason, without notice. The same goes for closing off comments, in a thread or overall in the blog.
2. If I EDIT your comment and still leave it up over your name, I will post a notice saying I’ve done so. I feel strongly about this; the blog editor’s refusal to adopt the same policy is the principal reason I no longer blog at Computerworld, despite the high regard in which I hold the print publication and almost everybody on the staff. (I continue to be very happy as a columnist there.)
3. The usual no-nos are forbidden here — plagiarism, spam, death threats, etc.
| Categories: About this blog | Leave a Comment |