Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Database Decision Tree?
 Date: Fri, 19 Oct 2001 23:49:00 -0700 From: Ronald Bourret <rpbourret@r...> But what I'm not convinced of is that, should native XML databases succeed, the bureaucracy controlling what goes into the database won't try to take them over. But what do you mean, in this context, by "succeed"? If the native XML DBMS's succeed in supplanting the relational DBMS's, and taking over their role as the "database of record" for the classic kind of key corporate data that has to be accessed by many different groups, then yes, the DBA's would then become the lords of the native XML DBMS. However, I don't think that's the kind of "success" that native XML DBMS's are currently looking for. I think it would be very hard for them to succeed at that. Why should people currently using RDBMS's for their classic key corporate data have any interest in converting to XML as a data model? After all, the relational model basically serves their needs pretty well. There is not currently an industry crisis among RDBMS users caused by deficiencies in the relational model. Furthermore, changing the data model in such systems from relational to anything else would entail a huge amount of work and risk. A vast superstructure has been built around these relational databases: report generators, reports written for those report generators, all kinds of tools and add-ons from the relational database vendors, the fact that lots of people have been trained in concepts of third normal form, the SQL language, and so on and so forth. The image of native XML DBMS's trying to supplant relational DBMS's, trying to take them over and replace them, is a strawman, and we need not waste our time thrashing it. I think the problem arises from the use of the term "DBMS" (or "database"), because it can be interpreted in a narrow sense or a broad sense. In the narrow sense, a DBMS is in charge of the "data of record" holding classic key corporate data, being used by many groups for widely different purposes and widely different computing environments, supporting ad hoc queries, and on and on. In the broad sense, a DBMS is software that manages data, doing some useful things for you. There is a long menu of data management services that you might want or not want. Any application needs a certain subset of these services; any DBMS-in-the-broad-sense) provides a certain subset of these services. When we use the phrase "native XML DBMS", I think we are using DBMS in the broad sense. Of course the broad sense is a lot less specific, since it doesn't say which of the services we're talking about. So it's hard to generalize about native XML DBMS's. In order to get specific and get down to the real facts, you have to talk about use cases: what is the native XML DBMS for in this case, and what are its responsibilities in this case, etc. I think this is a very good point. Native XML databases look like a good way to integrate data from a variety of backends, and I think the winning native XML databases of the future will do this transparently and bi-directionally. (Some are already doing it today.) Relational databases may have problems in this area, since the result of integrating data from a variety of sources is likely to be semi-structured data, not structured data. -- Ron I agree very much that integrating data from a variety of backends is one of the promising areas for native XML DBMS's, and that ability to handle semi-structured data is a key benefit. Some native XML DBMS's are also well-suited to serve the role of a middle-tier persistent transactional distributed cache. Often such a cache is also doing the kind of data integration you discussed above. -- Dan 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
