Slashdot Mirror


Enthusiasts Convene To Say No To SQL, Hash Out New DB Breed

ericatcw writes "The inaugural NoSQL meet-up in San Francisco during last month's Yahoo! Apache Hadoop Summit had a whiff of revolution about it, like a latter-day techie version of the American Patriots planning the Boston Tea Party. Like the Patriots, who rebelled against Britain's heavy taxes, NoSQLers came to share how they had overthrown the tyranny of burdensome, expensive relational databases in favor of more efficient and cheaper ways of managing data, reports Computerworld."

1 of 423 comments (clear)

  1. Re:A time and place for everything by diamondmagic · · Score: 5, Informative

    Design an efficient table relating a tree structure.

    Huh? Tree structures are best handled by relational databases, as it is far faster then recursion. Give row a unique ID and a parent ID, and in addition, a left hand and right hand number, the root node having a left-hand value of 1 and a right hand value of (number rows * 2), the first child node has a left-hand value of one more than the parent's, the right-hand value is one less then the left-hand of a younger sibling.

    Then design queries to answer questions such as:
    * Find the nodes in the subtree under B.

    SELECT * FROM rows WHERE left > [left hand value of B] AND right < [right hand value of B]

    * Find all ancesters of G

    SELECT * FROM rows WHERE left < [left hand value of G] AND right > [right hand value of G]

    * Find the nearest common ancestor of D and H

    SELECT * FROM rows WHERE left < [lowest left hand value from D,H] AND right > [highest right hand value from D,H] ORDER BY right LIMIT 1

    Trees is a wellknown problem of SQL, but the fact is that SQL can't handle most datastructures and complex relations, only very simple one dimensional ones.

    Are you saying trees are easy or hard? And for more complex systems, that is what JOINs are for. SQL is by far the most powerful way and often the fastest way to manipulate data that I know of. The only time I can recall that I had to use a non-SQL solution that was faster then the SQL solution was a matrix operation.