October 13, 2005
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.
Comments
3 Responses to “It’s not about a single database”
Leave a Reply
So your customers are so different that your going to rely on something other than relational to capture the differences? I’m not sure how a pervasive one-off strategy like this will enable “profiling” at all.
This is similar to saying “strings are going to be the basis of text documents.” What does “be the basis” mean? Do you mean XQuery will be used to query all text data – and if so, what about any sort of comparison between XML and non-XML data? How will such queries work?
hahahahahahaha… oh, you’re serious? Why on earth would they do that? Although I guess here it depends on what you mean by “database.”
Tied together how? And the phrase “some other data models as well” is just a cop-out… presumably DBMS2 is “about integration”, but beyond that, I still don’t know what you mean. Integration is complex and a worthy topic, but… not sure what’s actually being said in any of this.
Warning — that tone, if continued, will lead to a rapid end of this discussion.
Anyhow, if you’re not aware of XML’s role in EII, I’m not going to try to educate you at this moment.
As for the customer profiling — it’s not so much that that the customers are different, as that the available information about them will be. In part this is due to differences in what people voluntarily share. In large part it’s because gathering customer information is a very valuable thing to do, and enterprises keep trying tactic after tactic to do so, whether or not that particular kind information is available for ALL customers and prospects. And in many cases this won’t be actual customer information so much as analytically derived “information” — which, again, may be valid for some customers but not for all.
If you work in mass-market CRM, you probably have some idea of what I’m talking about.
Sorry – while I was being smart, I didn’t realize I was that offensive.
There’s a difference between current role in the market, and actual value. If you had your drothers, don’t you think a clearer integration language would be better? Surely you’ve seen better languages and syntax than XML.
An additional question is “which XML”? Just saying “XML” doesn’t say much about what schema(s) will be useful for database integration.
That makes another point: I’m familiar with EAI, which currently uses XML messages between applications. The descriptions I’ve read of EII are flaky – if you can point me to a good one, I’d be grateful. Using XML to describe data, though, is problematic – it might (?) be fine for text markup, for a single document. But XPath and XQuery are extraction functions, not description. Does XML have a way to describe anything more than documents of a single “type”?
Much complexity is inherent in integration itself, but I think XML helps more than hinders.
I fully agree that analysis derives information from sources. So let me see if I get what you’re aiming at: you’re talking about the storage of unprocessed sources, pre-analysis, and then a later extraction of structured data from those sources? I don’t disagree with all that, but if your sources are “raw”, they won’t all be XML. And if you’re constructing an XML structure for them, transforming various “stuff” into XML documents, you might as well be populating a database with better structural definition and query capability than XML. Even SQL delivers that.
Later, when you apply more analyses to the raw sources, you get more structured data.
So… is DBMS2 about “raw storage” for unprocesses sources, pre-analysis?
No, I don’t.
– Eric