Re: The State of Native XML databases

[Ilya Sterin]

Ah, never mind, I just noticed that Jeff from RD commented already:-)

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,
> >
> > 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 <http://x-query.com/mailman/listinfo/talk> 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/
> > >>
> > >> _______________________________________________
> > >> http://x-query.com/mailman/listinfo/talk
> > >> http://x-query.com/mailman/listinfo/talk
> > >>
> > > _______________________________________________
> > > http://x-query.com/mailman/listinfo/talk
> > > http://x-query.com/mailman/listinfo/talk
> >
> >
>