I think it is entirely possible and I am sure the "relational" folks will disagree. The biggest issue/risk is how do you do what the "relational" people do naturally? Which is create relationships between "documents".
If you design a DB relationally for an enterprise and leave out all of the foreign keys, then the question is how do you link the data together. Data in tables without relationships to other tables is of limited value. For instance, if I have an invoice table without any "relationship" to the customer it belongs too, then it is of limited value. At the same time, if your data is "normalized", trying to build a hierarchical document out of the data is going to mean either a massive join or a lot of hits to the database. Is your data predominately Hierarchical or Relational? And if it is predominately Hierarchical and has relationships between documents how do you define the relationship? Currently, there isn't a "join" mechanism, so you have to hit the database again for any and all relationships. Basically, you have to do the join yourself. Creating reports in a Relational model can be done through standard report utilities. Most of these use JDBC so all you have to do is define the SQL and then tell it where to put the results. With an XML document that is changing over time, reporting gets a bit more interesting. It all comes down to requirements. Relational models have fixed table layouts, not that they can't be changed, but they only support one schema at a time. Yes, you can impose that on an XML document, but I think that is benefit. It means that your code has to be flexible to handle the differences. With a relational model, changing a table requires that you review the SQL to make sure nothing breaks. With an XML document, you either do the same thing or you plan ahead and as you parse you react. In addition, relational databases are more "mature" than other databases, because they have been around awhile and people have run into problems that the first databases didn't solve and added support for triggers and such. All in all, depending on the complexity of your data and how inovative you want to be, yes you can use XML, but should you? I am and my entire product is built around it, but I planned ahead and I don't try and lock anything down. HTH, Mark P.S. Let the flames begin ;-). Duncan Swain wrote: > Hello all, > > I am interested in your opinion on how much success I am likely to find > trying to use an open source native xml database to support a typical > small growing enterprise. My intention is to drop the distinction > between data and document. A document would be either structured, > unstructured, but most often somewhere in between. I am thinking of > maintaining one xml schema which is in continual flux as the company > grows. This schema would probably always be used for validating new > documents, but only sometimes used for validating retrieved documents > (when exchanging the document with a business partner for example). > Documents would become more structured as the enterprise develops its > business model and understands the benefits of more structure. More > document types would be discovered and included in the schema as > business processes develop. Html interfaces would auto-generated with > xslt stylesheets for displaying retrieved documents. The schema would be > transformed to create html forms for creating new documents. Editing > outdated documents would involve either validating it against the new > schema or simply throwing back into the store. > > I expect my problems are going to center around maintaining links > between documents. I've been thinking of using Mozilla's support for > simple type XLinks for this. Generating an html form for creating a new > "Project" would involve transforming the Project element of the schema, > and when an aggregated element is found, "Person" for example, the > database would be queried to construct a list of xlink hrefs to people. > When the document is retrieved the link could be used to drill down to > the aggregated document. Xindice has an experimental feature called > autolink which seems to address this. > > Thanks in advance for your consideration of these issues and many > regards, > > Duncan Swain
