Comments on: XML versus sparse columns in variable schemas http://www.dbms2.com/2008/03/28/xml-versus-sparse-columns-in-variable-schemas/ Choices in data management and analysis Sun, 20 Jul 2008 13:59:05 +0000 http://wordpress.org/?v=2.5.1 By: Travis Spencer http://www.dbms2.com/2008/03/28/xml-versus-sparse-columns-in-variable-schemas/#comment-90828 Travis Spencer Thu, 17 Jul 2008 07:46:13 +0000 http://www.dbms2.com/2008/03/28/xml-versus-sparse-columns-in-variable-schemas/#comment-90828 @Ning: Besides performance and features, the other barrier is cost. ATM, the native XML database of choice is MarkLogic and they know it. So, they charge you an arm and a leg for it. The list price is 6 figures IIRC. @Daniel: Simon's example that includes typed metadata is a case of what some call EAV/CV (http://en.wikipedia.org/wiki/Entity-Attribute-Value_model). The metadata to create this type system is in the RDBMS as well, and your application essentially becomes the referential integrity engine. Fun times! @Ning: Besides performance and features, the other barrier is cost. ATM, the native XML database of choice is MarkLogic and they know it. So, they charge you an arm and a leg for it. The list price is 6 figures IIRC.

@Daniel: Simon’s example that includes typed metadata is a case of what some call EAV/CV (http://en.wikipedia.org/wiki/Entity-Attribute-Value_model). The metadata to create this type system is in the RDBMS as well, and your application essentially becomes the referential integrity engine. Fun times!

]]> By: Daniel Weinreb http://www.dbms2.com/2008/03/28/xml-versus-sparse-columns-in-variable-schemas/#comment-80125 Daniel Weinreb Sun, 30 Mar 2008 16:13:51 +0000 http://www.dbms2.com/2008/03/28/xml-versus-sparse-columns-in-variable-schemas/#comment-80125 To make this mode of operation useful, there would be one column that contains a value that says what type this row is, and there would be metadata somewhere that says which columns are relevant to this row. (For XML, your metadata would say even more, namely where each column corresponds to which element or attribute in an XML schema.) This is basically a cheesy way to do polymorphism, in RDBMS's which don't have this kind of polymorphism natively defined. Simon claims you have strongly-typed data, but what in the DBMS stops you from inserting a row representing socks but setting the cup size? And what if you have special sports socks, which have an additional attribute saying what sport they're aimed at? This column should be empty for regular socks. That's a simple example of inheritance. You can represent the rows just fine but you need the metadata somewhere, and I don't see how it would be in the DBMS, so the DBMS's ability to do integrity checking is limited. To make this mode of operation useful, there would be one column that contains a value that says what type this row is, and there would be metadata somewhere that says which columns are relevant to this row. (For XML, your metadata would say even more, namely where each column corresponds to which element or attribute in an XML schema.) This is basically a cheesy way to do polymorphism, in RDBMS’s which don’t have this kind of polymorphism natively defined.

Simon claims you have strongly-typed data, but what in the DBMS stops you from inserting a row representing socks but setting the cup size?

And what if you have special sports socks, which have an additional attribute saying what sport they’re aimed at? This column should be empty for regular socks. That’s a simple example of inheritance. You can represent the rows just fine but you need the metadata somewhere, and I don’t see how it would be in the DBMS, so the DBMS’s ability to do integrity checking is limited.

]]> By: Ning http://www.dbms2.com/2008/03/28/xml-versus-sparse-columns-in-variable-schemas/#comment-79855 Ning Sat, 29 Mar 2008 00:33:54 +0000 http://www.dbms2.com/2008/03/28/xml-versus-sparse-columns-in-variable-schemas/#comment-79855 Exactly. This is one of the sweet spots of XML databases: schema evolution and schema chaos. With relational views defined on top of XML data, application designers should not feel lost. I guess the major reasons that prevent them adopting XML by now are performance and operational completeness, which should be mature eventually. Exactly. This is one of the sweet spots of XML databases: schema evolution and schema chaos.

With relational views defined on top of XML data, application designers should not feel lost. I guess the major reasons that prevent them adopting XML by now are performance and operational completeness, which should be mature eventually.

]]>