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."

Comments

Re:A time and place for everything

[julesh]

SQL is great for financial data.

Actually, this isn't true either. See this article for pointers to some of the failings of SQL in dealing with financial data, particularly time series (e.g. sales figures, share prices, etc.). Here's another take on the problem, which essentially is that SQL doesn't recognise that there can be relationships between the rows of a table (e.g., "this happened after this").

Re:A time and place for everything

[diamondmagic]

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.

Re:A time and place for everything

[Kjella]

1) 1996 called, they want their arguments back. For example, most RDBMS have ranking functions now.
2) Even in 1996, he doesn't know SQL worth shit

SELECT (prev.sales+now.sales+next.sales)/3 three_day_average
FROM sales prev,
              sales now,
              sales next
WHERE prev.day_number = now.day_number-1
AND next.day_number = now.day_number+1

Easy as pie making most of the calculations he wants. Maybe he should ask someone knowledgable in SQL?