Just a little more about what I am trying to do... I am starting a company offering my services to small companies with information management needs. As a case study, imagine a typical company with 10 employees. They have made a minimal investment in IT. They run a network of windows machines, timesheets are managed in an Excel spread sheet on a shared network drive, the boss consults the spreadsheet every two weeks and writes paycheques, contacts are duplicated everywhere in Outlook, CVs are in someone's My Documents folder (but no-one seems to know where), some ambitious individual has attempted to create some Word templates for agendas and minutes but now they duplicated and diverging and not always being used. A network administrator comes in every Friday afternoon and spends his time checking for viruses. He tries to stress the importance of a "real" server and a backup strategy.
Mark asks: > Is your data predominately Hierarchical or Relational? The answer is "both". To propose my client grasp the difference between content and view and drop their beloved Word is one thing. Proposing that the company maintain not one but two schemas - one for hierarchical documents and another for relational data - is another. Not only that, two database products purchased and installed, different tools for authoring each schema, and I must be retained to coordinate the two schemas and evolve each one. And what about documents? They *are* typically related. We still need a solution for that. I am proposing (of course for argument's sake:o) that a pragmatic solution for this case study, one that may actually be adopted and be useful today, is one that treats all data as document and relies on middleware for linking. ----- Original Message ----- From: "Mark J. Stang" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, May 29, 2002 8:29 PM Subject: Re: Native xml db for small enterprise with evolving schema > 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 >
