The STAR eXchange

One of the constant themes I hear about users in STAR is the size of the XML files. That there is a problem parsing them, processing them, and in general trying to cram them into legacy data stores and using legacy technologies. One of the unfortunate side affects of data binding of XML is that everybody tries to use it for everything. The first and typically last tool a programmer will go for now a-days is a data binding framework. Unfortunately, this is not necessarily the best choice. In many cases, if you dig around in the xml tool bag you can find other choices.

Kurt Cagle has written an excellent rebuttal on the FUD (Fear, Uncertainty, and Doubt) that XML is not right for BIG Data. When we are talking BIG we are talking 50MB or larger. In fact, he rightly says:

Frankly, if you ARE storing your XMLdata in a relational database repository, then you’re throwing valuable money away, because you’re adding a hideous performance penalty on every transaction.

Kurt Cagle, XMLToday.com

He goes on to talk about the role of XML Databases and how in many ways they are out performing their relational database counterparts. STAR has several very large BODs that may need to be processed and queried. PartsMaster, LaborOperations, PartsPriceList, and RepairOrder are a few that come to mind. Processing these with data binding is definitely not the way to go. Supplementing an existing Relational Database with an XML Database can be very beneficial. It also allows you to work with XML natively without necessarily having to do a data transformation to get at the relevent information. Investigate your existing Relational Database as many have XML Data Storage abilities. XML can be a good fit for Big Data, it just takes using the right tool for the right job, and not trying to use the same tool for every job.