as far as I understand it, shredding hiearchical documents into a relationa store is optional feature of Oracle XMLDB
http://www.oracle.com/technetwork/database-features/xmldb/xm...
It is called XMLDB structured storage (vs binary storage, that one actual stores the hierarchical XML naitively)
The XMLDB structured storage I think has been available since 2003 (but I might be wrong there).
Oracle's XMLDB structure requires XSD declaration. Within that declaration XMLDB can use 'hints' to indicate if a given set of attributes across documents is related. And if yes, it will shred the docs in a way that the related attributes will be co-joined.
The advantage, as the author of ToroDB noted below is
a) space saving
b) ability to use relational joins that are using disk-optimized access strategies.
The disadvantage (at least in Oracle XMLDB structured option) -- is the need for declaration of the model ahead of time, and joins for deeply/complex structured documents.
It looks like ToroDB 'senses' the model of each document on the way in. I think there are definetely use cases for this approach, that tolerate the trade off between ingestion speed and storage control.
Plus using a relational engine underneath allows for ACID properties (eg multi-object rollback/commmits) -- which native mongo does not provide.
http://www.oracle.com/technetwork/database-features/xmldb/xm...
It is called XMLDB structured storage (vs binary storage, that one actual stores the hierarchical XML naitively)
The XMLDB structured storage I think has been available since 2003 (but I might be wrong there).
Oracle's XMLDB structure requires XSD declaration. Within that declaration XMLDB can use 'hints' to indicate if a given set of attributes across documents is related. And if yes, it will shred the docs in a way that the related attributes will be co-joined.
The advantage, as the author of ToroDB noted below is a) space saving b) ability to use relational joins that are using disk-optimized access strategies.
The disadvantage (at least in Oracle XMLDB structured option) -- is the need for declaration of the model ahead of time, and joins for deeply/complex structured documents.
It looks like ToroDB 'senses' the model of each document on the way in. I think there are definetely use cases for this approach, that tolerate the trade off between ingestion speed and storage control. Plus using a relational engine underneath allows for ACID properties (eg multi-object rollback/commmits) -- which native mongo does not provide.