Re: The State of Native XML databases

[Ilya Sterin]

Let me add to that.  In many cases the self-describing nature of XML
is a plus in many messaging and various other scenarios where a data
model is not complex and validation through code or non-validation is
OK.  You wouldn't impose that level of loosely constrained scenario is
a case where you're persisting your application's business state which
requires various constraints imposed on the data.  Yes, as anything
else this can be done in the application, but if we're ever to persist
such data in a native XML format vs. reserving to marshaling to a
relational format and unmarshaling into schema for standardization
purposes, these constrains must be imposed by the database itself.
Further, even if we don't agree on the usefulness of schema, more
granular isolation level definitely allows XML databases to be taken
more seriously in environments where high level of concurrency is a
must.  This is an argument of table level vs. row level locking.  With
a relational model it's a bit straight forward, since a tuple
represents the lowest isolation level due to it's structured nature.
With XML, it's a bit more complex, since there is no clear line in
what constitutes a true unified atomic record and locking at each
element/attribute level would be a huge performance bottleneck.  You
should really take a look at the newest TigerLogic 3.0 and see
benefits offered by such features and how locking can be controlled,
etc...  I bet some will consider xml database for persisting data they
never thought about persisting before due to architectural
limitations.  Please don't think I'm trying to sell TL for one reason
or another, I have absolutely no bias nor benefit in doing so.  This
is strictly from an experience in trying to architect an application
in which the state is mostly based on a standardized industry schema
and storing this data in a relational store would be a useless
overhead.  RainingData was the only viable solution at this time, but
my hopes are that other vendors are going to get on board one of these
days.

Ilya



On 8/20/07, Ilya Sterin <http://x-query.com/mailman/listinfo/talk> wrote:
> On 8/20/07, John Snelson <http://x-query.com/mailman/listinfo/talk> wrote:
> > Ilya Sterin wrote:
> > >> Some type of schema can of course be useful in different scenarios, but
> > >> Ilya's suggestion that "ddl=xml schema" does not suit everyone.
> > >
> > > Yeah, if you are not looking at XML as a persistence.  You wouldn't
> > > work with a relational store without a DDL, be it SQL or any other way
> > > to define your schema.  Yes, there are many use cases for using xml in
> > > its semi-structured loose format, that's just not for persisting
> > > application state per say, rather message snippets, configs, etc...
> > > Again, you could also argue that MySQL was useful before InnoDB was
> > > introduced.
> >
> > Unlike the relational data model, XML is (can be) a self descriptive
> > format. This is why it is easy to use an XML database without a schema,
> > whereas it is impossible with a relational database.
> >
> > With the XML data model, you have built-in schema evolution
> > capabilities. If you impose a schema (XML Schema or otherwise) on your
> > XML database, you loose that ability - and have to re-implement it in a
> > convoluted way if you need it back again.
>
> I do agree with you in some cases, but as far as schema evolution,
> this is where versioning comes in.
>
> >
> > John
> >
>