Re: The State of Native XML databasesIlya Sterin sterini at gmail.com
Mon Aug 20 14:13:11 PDT 2007
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 > >
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format