
CoSQL: SQL and noSQL are really just two sides of the same coin - jforman
http://cacm.acm.org/magazines/2011/4/106584-a-co-relational-model-of-data-for-large-shared-data-banks/fulltext
======
rch
This article turned out better than I thought it would.

Here's why: "In this article we present a mathematical data model for the most
common noSQL databases—namely, key/value relationships—and demonstrate that
this data model is the mathematical dual of SQL's relational data model of
foreign-/primary-key relationships."

~~~
Confusion
Seeing the author immediately increased my expectations:
[http://en.wikipedia.org/wiki/Erik_Meijer_(computer_scientist...](http://en.wikipedia.org/wiki/Erik_Meijer_\(computer_scientist\))

~~~
luke_s
Erik Meijer gave a presentation on this during YOW 2010, in Melbourne. The
ideas are very deep, and I hope they will be taken on board by the IT industry
and find practical applications. It would be nice to think that at YOW we
witnessed part of the birth of an idea, that will revolutionise the way think
about data storage.

~~~
endgame
That was a fantastic conference. I enjoyed Erik's presentations. Guy Steele's
lecture was also very good, but his keynote with Richard P. Gabriel was
incredible. He's actually done the 50 in 50 keynote before:
<http://blip.tv/file/1472720>

------
techtalsky
I actually see this article as a good sign. This kind of article could set the
tone for the beginning of sane discussion about the SQL/coSQL ecosystem and
how to move forward in developing a shared toolset for developers.

------
antirez
the author mentions Redis but fails to analyze the peculiar data model of
Redis that I think can't be considered mathematically dual with SQL's
relational model... unless you want to use every row of a table as a node with
fields for pointers and build skip lists out of that...

The fact that Redis is analyzed as a KV store is already a big enough proof by
the over simplification that the author is performing here, in the name of
proving his point.

~~~
alexpopescu
@antirez as in any mathematical proof the most generic case is considered
first. If X is a special case or is exposing special corner scenarios, I'd
assume that could be covered by extension proofs.

I'm not saying Erik's article is bullet proof. But it offers a very
interesting perspective on two data models that were considered conflicting.

~~~
stephth
But should Redis really be part of that list? I feel like the strongest point
of Redis is that it realistically allows devs to forget about any complex
relational models living outside of the code logic, like the ones referred in
the article. Other "NoSql" databases _look_ like Redis, but the huge
difference with the latter are its atomic operations on simple data structures
(append, inc, push, intersect, union …). Redis is the only database that I
know of that safely allows the developer to deal with relational data in such
a straightforward, close-to-programming manner, and still talk with it at a
pretty low level (without having to use mapper abstractions). The "data
structure server" description probably serves the project better than "key-
value store" in that sense.

------
a18x
I'm amazed how people tend to overcomplicate simple things. Isn't the noSQL
algebra is just relational algebra without the Cartesian product operator?

~~~
kenjackson
Huh? I'm going to need more than hand waving to get that assertion. Please
expand.

~~~
a18x
Continuation of the previous post... Why wouldn’t the noSQL providers use SQL
as a starting point? Take SQL standard, relax transactional requirements from
ACID to BASE, add functions for searching in columns, add a note that
execution of queries with Cartesian product may be extremely slow (with Map
Reduce or other parallelization technology. Let the database vendors compete
in that field). I recommend book “Data-Intensive Text Processing with
MapReduce” by Jimmy Lin and Chris Dyer book for further reading on how to
implement relational joins with MapReduce. DML and DDL will be changed
substantially, though. Drop or relax relational constraints, different table
definition etc. As for coSQL, it looks to me like it introduces Codasyl-syle
queries instead of relational algebra.

