[xquery-talk] Re: The State of Native XML databases

[John Snelson]

Ilya Sterin wrote:
> On 8/20/07, John Snelson <john.snelson at oracle.com> wrote:
>> Ilya,
>>
>> Even if I ignore your use of the amorphous and irrelevant term "native
>> XML database", there are still some pretty tall claims in this email.
> 
> Yeah, Oracle has a way of shunning away from this term, understandable.

The term means different things to different people. Some people think 
it means the storage model, some people think it means XQuery support, etc.

If you need to use the term, I think the best definition is supports the 
XML infoset for input and output, and possibly that it supports a 
standard XML query language like XPath or XQuery. All other issues that 
get rolled into the term are irrelevant.

>> You use the term "enterprise persistence" without any kind of
>> definition. Can you let us know what "enterprise" use cases are handled
>> by TigerLogic that other XML databases cannot handle?
> 
> Sure, I understand that most use this term religiously without truly
> understanding the meaning, not that I do per say, but here is what it
> means to me.
> 
> A persistence mechanism that can scale in a highly concurrent
> environment without employing a lot of architectural changes on the
> client (application client I mean).  Of course any application should
> be architected to scale from the start and many apps can work with
> limitations of their technologies to apply workarounds.

This is certainly a valid use case, and I'm sure that a number of XML 
databases can manage this. I also know other "enterprise" use cases that 
involve very large databases of never or very rarely updated data - 
people data mining genetic records seem to favour XML databases, for 
instance.

> Our biggest issue with Oracle and XMLDB were the fact that there is
> absolutely no transactional integrity outside of a collection entry.
> Each write to a particular collection entry requires a lock of the
> document stored.  To me that's equivalent to locking a database table
> each time an update transaction occurs.  We talked to Oracle about
> this extensively and they refused to even listen, mostly because the
> not so knowledgeable SEs that we were dealing with had no clue what we
> were talking about.  Now, the issue can be resolved by shredding your
> document into units that you want to maintain the integrity and
> participate in concurrent read/writes.  That's a huge architectural
> limitation.  That means that we now have to take a quite complex
> schema that our industry is working with (CDISC ODM) and instead of
> utilizing native xml technologies to read/write an xml documents, we
> now have to worry about completely irrelevant concepts of collections
> that are not defined by the schema, but rather is specific to an
> application and how we decide to shred and store the data.  That also
> limits the integrity that can be enforced with schema-bound
> collections.  (notice, I use collections here, though I wish I could
> get rid of this and instead say schema period, representing a database
> instance that's schema bound.

I'm sorry you had a bad experience with Oracle's XML DB, however I'm 
afraid I can't comment on your experience because I work on another XML 
database for Oracle, Berkeley DB XML.

Berkeley DB XML has page level locking, where a page is a user defined, 
fixed length record. This means that it will certainly provide you with 
a sub-document granularity of locking.

John