• patrickmcginnis59 10839 (7/21/2014)


    Eric M Russell (7/21/2014)


    patrickmcginnis59 10839 (7/21/2014)


    Eric M Russell (7/21/2014)


    It's interesting that developers on the various "NoSQL" platforms are now focussing their efforts on implementing SQL language interfaces. Apparently when it came time to start capitalizing on their inventions and paying the bills, they discovered that the corporate world isn't interested in learning how to write code in some geeky new syntax like MapReduce.

    I don't think that SQL is that bad a language, and I also don't think its too late for anyone to learn SQL. Heck its even possible that an SQL statement could be translated into a map reduce job. I think with some of the larger NoSQL sites it makes darn good sense to automate query construction, and thats SQL's strong point, it by definition doesn't necessarily specify how to put query results together, and I'm betting putting together a query for some of those big NoSQL databases is a pretty nontrivial job thats ripe for automation, so why not use a familiar syntax for the job?

    That's exactly what HivSQL does, it's an ODBC compliant provider that translates SQL into MapReduce. HCatalog is a meta-data service that translates physical file locations into logical table names.

    I worked a bit with Unidata which wasn't very relational at all (I think its one of the so called "multi valued" databases), or rather, the vendor said it was "nested relational". One of the interesting things was its odbc driver, a unidata table could have a "field" that could itself be a table (thats why it was sometimes called "nested relational"), and the odbc driver could make it appear as another table, and when queried with a join to its containing table, pretty much translated into a regular read of each record then cycled through its contained record in that field. The closest I could think it looked like was something like Oracles "repeating groups" (VARRAY).

    People do that, with limited success, in SQL Server and Oracle using XML columns.

    http://technet.microsoft.com/en-us/library/ms191497(v=sql.105).aspx

    SQL Server's Column Sets are also a form of XML datatype, except the columns are not nested.

    http://msdn.microsoft.com/en-us/library/cc280521(v=sql.105).aspx

    But MongoDB probably handles nested XML documents better, because the data and index structures are optimized for it.

    I believe that going forward most enterprise database environments will be like a three ring circus with the relational database working in conjunction with something like Hadoop for bulk archival and analytics and MongoDB for document stores. Folks may start loving their SQL Server database even more, once it can focus on what it does best and stops being used like a jack of all trades.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho