The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Native XML databases?

Does anyone have experience with native XML databases?  Is this where all the object databases went when their market didn't materialize?  What sort of scale can they handle?  What operations do they do well?  poorly?  Specific product recommendations or un-recommendations?

I'm thinking about trying to use one for object persistence, where I need to do nice cross-type queries, free-text searches, non-rigid metadata, etc.  I have the relational-database expertise (and familiarity with Hibernate, etc.) to attempt this in RDBMS-world, but I'm wondering if any of the native XML databases would be worthy of consideration here.

(Substantial hurdles in my mind include scaling to large numbers of objects, tunability, lack of customer familiarity, relative immaturity of the technology, etc.)
schmoe Send private email
Tuesday, April 19, 2005
 
 
We had a look at Fujitsu's Content Wiz as a method for joining disperate data sources,  part of this was to make things available through an Virtual XML Schema, and to be able to then do further content massaging through use of XQuery/Xpath.
Was interesting, but I think we saw a beta so we haven't started using it yet.
gorf Send private email
Wednesday, April 20, 2005
 
 
I used Xindice a year or two ago and found it to be interesting but immature. I've recently started using eXist (exist-db.org) and found it to be much more usable. So far I'm not using it for anything where massive scalability is an issue; I've been told that it can be made fairly performant with user-defined indexing, etc. The author has written some scholarly papers on the subject of fast XML indexing, which I haven't read. There are also a variety of live web apps running eXist which are linked from the product's site and which you can play with to get a feel for what sort of performance to expect.

It makes a lot of things really easy; my 'view record' screen consists of basically slapping a header and footer on the output of an XSLT document (stored in the NXD) applied to the record in question.

OTOH, it makes certain things a pain in the ass; there is no inbuilt relation system, so if you want to fake relationships of any kind you have to do it in the client.

eXist supports XPath, built-in XSLT with Xalan, XUpdate, and XQuery. XQuery looks pretty powerful; I've only just started playing with it. Support from the developers is excellent via e-mail and IRC and development is fairly active.

I've heard good things about X-Hive if you're interested in commercial products.
E. Naeher Send private email
Wednesday, April 20, 2005
 
 
NATIVE XML DATABASES ARE THE GREATEST THING EVER!

No, I'm kidding.  They were seen as the solution to everyone's problems, but they haven't worked out quite as smoothly as everyone hoped.

XML is not the Silver Bullet.  It is essentially the same as a text file though it offers some additional useful features such as validation, structure, etc.
KC Send private email
Wednesday, April 20, 2005
 
 
"XML is not the Silver Bullet.  It is essentially the same as a text file though it offers some additional useful features such as validation, structure, etc."

I've been trying to tell my current employer the same thing about our "source code". Really, it offers very few advantages over plain text files (except expressions and variables and data structures and flow control).
Benji Smith Send private email
Wednesday, April 20, 2005
 
 
XML is the "Emperor’s new clothes" of IT.
gilf Send private email
Thursday, April 21, 2005
 
 
"I've been trying to tell my current employer the same thing about our "source code". Really, it offers very few advantages over plain text files (except expressions and variables and data structures and flow control)."

I think in many cases it offers less. With a specifc plain text format the person specifing the requirements would generally include documentation on what goes where, any validation that takes place etc etc. With XML it's believed that every one knows what's going on by the virtue it's in XML. The biggest mistake is to use XML simply as a document format and not use/include the XSD/DTD capabilities therefore rendering it more complex than plain text.
gilf Send private email
Thursday, April 21, 2005
 
 
I think it's interesting that the hierarchical database model which was rejected so long ago in favor of the relational model is in vogue again now that it's called XML.
comp.lang.c refugee
Thursday, April 21, 2005
 
 
comp.lang.c refugee writes:

"I think it's interesting that the hierarchical database model which was rejected so long ago in favor of the relational model is in vogue again now that it's called XML."

My thoughts:
comp.lang.c refugee is a *very* wise man!

Peter
Peter Sherman Send private email
Friday, April 22, 2005
 
 
I've had very limited exposure to Tamino. It seems to me that as the traditional RDBMS'es (Oracle, SQL Server, DB2, ...) get more support for handeling XML data with every release, the window of opportunity is rapidly closig on these XML native engines as a broad general data storage alternative.
Just me (Sir to you) Send private email
Sunday, April 24, 2005
 
 
I have more than a sneaking regard for CODASYL type databases, adding dynamic relationships to both the heirarchy and the network would fix a great many of the problems.  But then that was exactly the kind of design work I was doing in '81.

Titanium is the closest implementation of that that I know, but it doesn't store XML nodes natively.
Simon Lucy Send private email
Thursday, April 28, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz