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

[Ilya Sterin]

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.

>
> For a start, not everyone likes or wants XML Schema - it does have a
> habit of turning an extensible format into a highly restricted one,

I don't necessarily debate the schema itself, but there must be a DDL
to represent the schema, right?  If you're talking about storing
semi-structured xml documents, then we're not talking about the same
thing.  In many cases, applications abide to storing content that is
validated by a standard developed using XML Schema or the likes, so
there must be a way to conform to such definitions.

> which I would argue was not very forward thinking. Only once in the 3
> years I've worked on Berkeley DB XML has anyone ever commented that we
> didn't use XML Schema (or any schema language) to restrict the data stored.

What do you guys use?  Again, I'm not saying that XML Schema should be
used, I was more looking into schema as a general term, we need
something to define the storage and constraints, right?

>
> 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.

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 briefly mentioned some issues in some of my xml persistence blog entries...

http://www.ilyasterin.com/enteprise_software/2006/09/xml_persistence.html

Let me see if I can get someone from RainingData to comment on this as well.

Ilya

>
> Also, I agree with Michael Kay that collections are in no way a
> relational concept - so this is another red herring.
>
> I'm not pretending to be partisan in this debate, but I do try to stay
> away from marketing spin and sweeping statements.
>
> John
>
> Ilya Sterin wrote:
> > I wish I could find more info on it.  The site states acid
> > transactions, but for people people unfamiliar with transaction
> > architectures, that doesn't equate being able to use it in an
> > enterprise application environment.  If consistency is enforced at the
> > collection entry level, that beats the purpose of having a native xml
> > database where ddl=xml schema.  In a perfect world, I wish the vendors
> > would get rid of the collection as a storage metaphor and instead
> > focus on defining schemas with one of the schema languages, which is
> > all that's needed.  Why mix relational concepts, which is what a
> > collection really is, with native xml hierarchal storage.
> >
> > We recently engage in numerous native xml storage projects and worked
> > very closely with RainingData on a TigerLogic 3.0 release.  As of
> > right now, that is probably the only truly native xml database that
> > defines all facilities needed for enterprise persistence in XML.
> >
> > Ilya
> >
> > On 8/19/07, Dr Orlovsky MA <dr.orlovsky at gmail.com> wrote:
> >> On Mon, 13 Aug 2007 22:01:19 -0400, Elliotte Harold wrote:
> >>
> >>> On another list I was recently asked to sum up the state of native XML
> >>> databases, especially open source ones. The result is here:
> >>>
> >>> http://cafe.elharo.com/xml/the-state-of-native-xml-databases/
> >>>
> >>> Comments appreciated.
> >>>
> >>>
> >> There is excellent native XML dsatabase completelly implementing XQuery.
> >> See for Sexdna XML database in google as well as look at the
> >> site
> >> http://modis.ispras.ru/sedna/
> >>
> >> _______________________________________________
> >> talk at x-query.com
> >> http://x-query.com/mailman/listinfo/talk
> >>
> > _______________________________________________
> > talk at x-query.com
> > http://x-query.com/mailman/listinfo/talk
>
>