This is our CTO at FusionWare Robert Houben's thoughts on the article. Robert is the Grandfather of ODBC, he created the first published ODBC driver outside of Microsoft and has been creating integration products for the Multivalue database since the early 80's, anyone remember PK Harmony.
Enjoy! So here is the real problem. The author of the article explains why the multivalues make life so much easier for developers, then tries to explain why they are bad anyways. Here is the snippet where he does this: "Fair enough. So let's look at an intensely practical reason why multi-valued fields are so bad. We query databases using SQL. The design of SQL is based entirely on the assumption that each column contains atomic values. If we run a normal SQL query against our single table solution: SELECT FName FROM CUSTOMER WHERE Hobby = "Rollerball" It will return zero rows; despite the fact that one of our customers plays rollerball, because there is no row with a field just containing "rollerball"." ----- end of quote ----- So this is the problem with his logic. The SQL SELECT statement was designed to work within the constraints of a single-valued first-normal-form environment. To predicate an argument against multivalues on the basis of a query language that assumes their non-existence is disingenuous. I'm surprised that a thinking person would do this. As *we* know, users can build very powerful, complex queries using the PICK LIST/SELECT syntax that accounts for multivalues, and the above observation is just plain bogus. There are other things wrong with the article, but the most compelling issue is that with the emergence of XML as a mechanism for processing complex data sets, multivalues have been reintroduced and are here to stay. If you look at it, both XPath and XQuery "understand" multivalues and allow you to build complex predicates that operate at the multi, sub, and sub-sub level. There are at this point MANY data environments where this takes place, including the DataSet object in ADO.NET and proprietary data objects from other vendors, which use XML as the underlying structure and allow nesting to take place. What Microsoft is doing with Access is simply to recognize the reality that many developers are already using XML to work around. The author's claim that "we query data with SQL" is no longer true. I would argue that XPath and XQuery are emerging as powerful, standards-based alternate query languages. Ignore them at your peril! ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
