Subject | Re: [Firebird-general] IBM moves the database goalposts - xml related |
---|---|
Author | Nando Dessena |
Post date | 2004-12-09T18:47:56Z |
Thomas,
T> Storing seems to be simple, because we do have LOB
T> data types in DBMS like BLOB, CLOB, ... But, there
T> might be semantic as well, because shall I be able to
T> store a not well-formed (wrong syntax => no end tag
T> for a start tag, ...) XML document or an invalid
T> XML document, in case the document needs to be
T> validated against a DTD or XML schema?
This is a different matter. Just storing is actually a burden with a
pure relational database. Because if I need to do anything with the
data (and I usually do, otherwise I'd store it in a bucket), I have to
normalize it, that is duplicate it. Plus, suppose the integrity and
authenticity of the documents I need to store is guaranteed by a
digital signature: in that case the normalized data is unreliable, as
the signed BLOB is what counts. This is suboptimal IMHO.
T> Some vendors do offer XML user-defined types. Whether
T> they support semantics as well, or if they simply are
T> derived types from single data types, that might be a
T> good question. For example, with DB2 XML Extender, you
T> can store an entire XML document in one field (using a
T> XML user-defined type), and by using a so-called Document
T> Access Definition (DAD) file, you are able to store
T> regular queried parts of the XML document in tables and
T> fields redundantly, in fields which can be indexed.
"redundantly" is the key here. As long as the redundancy is
automatically and securely delat with by the engine, then it might be
a way to go.
T> Querying? What would you like to have as a result-set?
Most frequently a list of matching documents. Since the document, in a
document-centered storage system, is itself atomic, there's no
practical need to extract a part of it.
T> Perhaps there are "XML-Enabled" (= (O)RDBMS with an
T> integrated XML thingy) databases out there which enable
T> you to store entire XML documents efficiently and
T> which will use on that type of information a XML
T> Query language to query XML data, again, retrieving
T> data in an efficient way as well. ;-)
It appears there aren't. Martijn argues that there's no need. I am not
so sure.
Ciao
--
Nando Dessena
http://www.flamerobin.org
T> Storing seems to be simple, because we do have LOB
T> data types in DBMS like BLOB, CLOB, ... But, there
T> might be semantic as well, because shall I be able to
T> store a not well-formed (wrong syntax => no end tag
T> for a start tag, ...) XML document or an invalid
T> XML document, in case the document needs to be
T> validated against a DTD or XML schema?
This is a different matter. Just storing is actually a burden with a
pure relational database. Because if I need to do anything with the
data (and I usually do, otherwise I'd store it in a bucket), I have to
normalize it, that is duplicate it. Plus, suppose the integrity and
authenticity of the documents I need to store is guaranteed by a
digital signature: in that case the normalized data is unreliable, as
the signed BLOB is what counts. This is suboptimal IMHO.
T> Some vendors do offer XML user-defined types. Whether
T> they support semantics as well, or if they simply are
T> derived types from single data types, that might be a
T> good question. For example, with DB2 XML Extender, you
T> can store an entire XML document in one field (using a
T> XML user-defined type), and by using a so-called Document
T> Access Definition (DAD) file, you are able to store
T> regular queried parts of the XML document in tables and
T> fields redundantly, in fields which can be indexed.
"redundantly" is the key here. As long as the redundancy is
automatically and securely delat with by the engine, then it might be
a way to go.
T> Querying? What would you like to have as a result-set?
Most frequently a list of matching documents. Since the document, in a
document-centered storage system, is itself atomic, there's no
practical need to extract a part of it.
T> Perhaps there are "XML-Enabled" (= (O)RDBMS with an
T> integrated XML thingy) databases out there which enable
T> you to store entire XML documents efficiently and
T> which will use on that type of information a XML
T> Query language to query XML data, again, retrieving
T> data in an efficient way as well. ;-)
It appears there aren't. Martijn argues that there's no need. I am not
so sure.
Ciao
--
Nando Dessena
http://www.flamerobin.org