[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] XML Database Decision Tree?
- From: Dan Weinreb <dlw@exceloncorp.com>
- To: Mike.Champion@SoftwareAG-USA.com
- Date: Sat, 27 Oct 2001 16:30:58 -0400 (EDT)
Date: Sat, 27 Oct 2001 15:58:15 -0400
From: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
I may be digressing, but an implication of an XML DBMS support for efficient
storage/retrieval of well-formed XML is that you can get many benefits of
using a DBMS without going through the agonies of data modelling, database
design, and performance tuning that RDBMS-based applications traditionally
suffer.
I don't think it's so much that XML means you don't need those
agonies. Whether you need them really depends on the role that your
DBMS plays on your organization.
Having a strongly-enforced strict and structured schema has benefit
and costs, which depend on the use case. That is, depending on what
you're trying to do, the costs might outweight the benefits or vice
versa.
In the classic "database of record" "standard corporate database" use
case, you've got a large corpus of critical long-lived corporate data,
and there are lots of different applications that might read and write
it (plus ad hoc queriers). To make sure that none of those
applications breaks another by writing something into the database
that another one can't read, you have to set up ground rules that all
the applications must follow. The classic RDBMS schema is part of
that set of ground rules, and there are these DBA guys who act as
judges (or perhaps "as bouncers") in order to prevent car crashes. I
think the need for these ground rules is pretty much independent of
what data model the DBMS is using.
(That is, if somehow someone ended up with a native XML database
playing such a role -- even though I keep saying that I don't think
that'll happen and that's not what native XML databse systems are
intended for! -- then you'd still want a schema for the same reason.)
In other use cases, rigid conformity may provide less benefit, and the
ability to manage semi-structured data may be more pressing. For
example, to again repeat the comments that you (Mike) made at the
NEJUG talk in Burlington, if a purchase order for $1M comes in, you
don't want to automatically turn it away just because it doesn't
conform perfectly 100% to your pre-defined schema! Semi-structured
data arises in more and more situations these days, including the
integration of data from multiple disparate sources. (Anyone
interested might want to do Web searches for papers about
semi-structure data.) I think this is one of the areas of opportunity
for native XML databases.