XML was never designed with this purpose in mind - to replace RDBMS. XML is simply a data representation format. Eventhough it is not uncommon to see people using XML as a persistent format( ie., to store and retrieve object states ) it is certainly not suitable for storing and manipulating millions of records as many of today's RDBMS does. Traditional databases also offer value-added features like indexing, record pagination, table level and row-level lockings, transaction management and SQL support etc. These de facto facilities are not supported by XML unless you write a custom framework that simulates an RDBMS kind of behaviour. So, the answer to your question is a big NO. XML is not going to replace industry strength RDBMS. However, XML will provide a cost-effective alternative for storing and manipulating smaller datasets. Since it is text-based, portable and has broad-range vendor support( parsers ) it will evolve as a very popular format for not only data storage, but also data exchange. Hope that helps, ------------------ Ajith Kallambella M. Sun Certified Programmer for the Java�2 Platform. IBM Certified Developer - XML and Related Technologies, V1.
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Hi! Ajith : Could you let me know how you prepare for IBM xml certificate? I have some question already post in another stand-alone topic. I' m currenty very interested in this part, please give me advice as much as you can. Thank you very much in advance!! Sincerely, Roger
Well, let me dream a little bit about what XML databases can look like. Of course, it is not going to happen for a while yet. Still, it is good to dream a little bit sometimes. We can certainly have an XML database that is based on a hierarchical database management system (eXchelon, an XML databse, the last time I looked, used ObjectStore as its native database). How the XML data is stored is not important for us here. As long as the data is stored somehow in an efficient way, that is good enough. If you need industrial-strength database management stuff, build it in. I will talk about what the database can do later on. Now, how do you connect to such a database? Well, you can specify a URI, no? For instance, suppose you have an XSLT stylesheet that you want to apply to an XML document stored in an XML database. You might specify something like http://www.xmlstoragedatabase.com/personnel.xml. Mind you, you are not getting the whole XML document back, because you don't need to (hereby solving one of the criticisms on XML data). With XSLT, that is all you need. When you issue an XPath expression against the XML "document", the XML database executes the XPath and returns whatever is necessary to you. So, your XSLT stylesheet processes merrily away, without knowing that the XML document is actually in an XML database,as there is no difference between that and an XML document sitting in your file system. But what if you want to manipulate the XML data in the database? Well, XML Query is coming soon, I hope. With that language, you essentially have a SQL for XML. Do whatever queries you need, do whatever updates you need, all in XML. But, how do we ensure the XML database's integrity is maintained? Well, that depends on how you describe the data in the database in the first place. I am not sure whether XML Schema allows you to specify referential constraints, etc. But I don't see why it can't be done somehow, through XML schema or not. Same with indexing, etc. So, you can build a very tough and scalable database for XML documents. It is not going to happen overnight, as relational databases did not become "fashionable" overnight either. Relational databases are really not the best way to handle hierarchical data, as XML documents inherently are. So I don't see why we cannot have XML databases and relational databases coexist peacefully together. In fact, they will probably be supported natively by the same database management system later on, when XML Schema and XML Queries mature to the stage that they can be used as the solid foundation for such a database. A side note on XSLT's need for getting whole XML documents: in general, XSLT stylesheets do not traverse an XML document fully. It might, but it does not have to. However, it does need something like random access to the document. This is the reason why many XSLT processors have to keep the whole XML document in memory. But this is really equivalent to having a in-memory XML database. ------------------ Khun Yee Fung Author of XSLT: Working with XML and HTML
Khun Yee Fung<BR>Author of <A HREF="http://www.amazon.com/exec/obidos/ASIN/0201711036/ref=ase_electricporkchop/107-0402457-1632559" TARGET=_blank rel="nofollow">XSLT: Working with XML and HTML</A>
If u look with respect to database, If you are inserting data into a parent table with a parent key, SQL does not allow: -- Duplicate values for the parent key -- If the parent key is a primary key, a null value for any column of the primary key -- Primary key-foreign key relationship like wise may be used in xml using xml schema....but i think u cant relate two xml files.But u can enforce unique key values...correct me, if anything wrong...
SCJP 1.5, SCEA, ICED (287,484,486)
Curse your sudden but inevitable betrayal! And this tiny ad too!
a bit of art, as a gift, the permaculture playing cards