Slashdot Mirror

Look here. Several of the products that he mentions are addons for PostgreSQL.

True, Xindice (Apache license, has reached version 1.0) looks good (I've no experience with it), but some of the original developers (Tom Bradford - dbXML, see below, and Kimbro Staken - Syncato, also below) of the source donated to Apache think they (Apache) haven't made the most of it. I don't know if this is true, and I don't know nor have any connections with either Bradford or Staken, but they seem like competent developers; they certainly churn out code - positive sign, right?

There is choice :): Check out Kimbro Staken's weblog Inspirational Technology (who also develops Syncato, an XML database weblog system using Berkeley DB XML.):

Consider Berkeley DB XML (currently at v1.1.0). Built on Berkeley DB and identically licensed (open source, free for non-commercial/development use, etc.); tons of APIs - can't get hold of the link but one of the developers (at least I think so) maintains a weblog of 'all' things Berkeley DB XML. Googleit.

Bradford recently released dbXML under GPL (commercial licenses available should you need it), there's a v2.0 beta available at the site.

Another native XML database is eXist, at version 0.9.2, java-based, LGPL licensed, I've only glanced at it, looks alright though I'm not the guy to say..

Then there're several commercial alternatives - X-Hive, Birdstep, Virtuoso, et al. - but this is Slashdot so..
Well, someone called Ron Bourret has compiled a full-bodied overview of XML databases, and have a big list of XML/DB links too (some link-rot). Goto.

True, Xindice (Apache license, has reached version 1.0) looks good (I've no experience with it), but some of the original developers (Tom Bradford - dbXML, see below, and Kimbro Staken - Syncato, also below) of the source donated to Apache think they (Apache) haven't made the most of it. I don't know if this is true, and I don't know nor have any connections with either Bradford or Staken, but they seem like competent developers; they certainly churn out code - positive sign, right?

There is choice :): Check out Kimbro Staken's weblog Inspirational Technology (who also develops Syncato, an XML database weblog system using Berkeley DB XML.):

Consider Berkeley DB XML (currently at v1.1.0). Built on Berkeley DB and identically licensed (open source, free for non-commercial/development use, etc.); tons of APIs - can't get hold of the link but one of the developers (at least I think so) maintains a weblog of 'all' things Berkeley DB XML. Googleit.

Bradford recently released dbXML under GPL (commercial licenses available should you need it), there's a v2.0 beta available at the site.

Another native XML database is eXist, at version 0.9.2, java-based, LGPL licensed, I've only glanced at it, looks alright though I'm not the guy to say..

Then there're several commercial alternatives - X-Hive, Birdstep, Virtuoso, et al. - but this is Slashdot so..
Well, someone called Ron Bourret has compiled a full-bodied overview of XML databases, and have a big list of XML/DB links too (some link-rot). Goto.

True, Xindice (Apache license, has reached version 1.0) looks good (I've no experience with it), but some of the original developers (Tom Bradford - dbXML, see below, and Kimbro Staken - Syncato, also below) of the source donated to Apache think they (Apache) haven't made the most of it. I don't know if this is true, and I don't know nor have any connections with either Bradford or Staken, but they seem like competent developers; they certainly churn out code - positive sign, right?

There is choice :): Check out Kimbro Staken's weblog Inspirational Technology (who also develops Syncato, an XML database weblog system using Berkeley DB XML.):

Consider Berkeley DB XML (currently at v1.1.0). Built on Berkeley DB and identically licensed (open source, free for non-commercial/development use, etc.); tons of APIs - can't get hold of the link but one of the developers (at least I think so) maintains a weblog of 'all' things Berkeley DB XML. Googleit.

Bradford recently released dbXML under GPL (commercial licenses available should you need it), there's a v2.0 beta available at the site.

Another native XML database is eXist, at version 0.9.2, java-based, LGPL licensed, I've only glanced at it, looks alright though I'm not the guy to say..

Then there're several commercial alternatives - X-Hive, Birdstep, Virtuoso, et al. - but this is Slashdot so..
Well, someone called Ron Bourret has compiled a full-bodied overview of XML databases, and have a big list of XML/DB links too (some link-rot). Goto.

There's more than SAX and DOM out there. What about data binding tools? Generate some classes from your DTD/schema, call bind(xmlFile) and you've got objects to work with.

There are even partial matching binding architectures. The best one I've seen is SNAQue.

> This is very much akin to having database schema for databases.

In fact there are many people proposing to store data as XML. I see a big danger here. Lots of people are encoding data with XML to enable exchange, and that's OK. But when people start thinking about storing that XML representation in a database, they fail to realize all the benefits that a relational database gives, both today with semi-relational SQL and in the future with fully-relational Tutorial D.

This approach had the same advantages and disadvantages of an "object oriented database". The data was too closely coupled to the applications. Adding a new field or index required modifying and recompiling all the applications and rebuilding the database.

The great advantage of a relational DBMS in a business environment is that it isn't closely coupled to the applications. For long-lived data, this is essential. That's why relational DBMS systems won out over explicitly-linked databases decades ago. They have the flexibility needed for long-term data storage.

Persistent data storage of language objects is an idea that keeps recurring in academia. It can certainly be done, but the long-term operational headaches aren't worth the short-term gain.

A related problem is the storage of data trees in databases. The current buzzword for this is XML databases, but systems for this go back a long way; check out MUMPS. You can store a tree in a relational DBMS by breaking up all the nodes into rows and using serial numbers to tie them together, but retrieval takes a huge number of lookups. You can also store a tree as a BLOB (a binary object that the database system doesn't parse), but then you can't search it. There's no general agreement on how to approach this problem yet, but this, not persistent object storage, is probably the way to go.

The database community learned painfully to separate indexing from structure. In SQL, you can do any search regardless of whether indices exist to make it fast. Indexing is a performance enhancement, and indices can be created later as needed to improve performance, without impacting programs. Any new database system should have that property.