

Sqlite and couchdb creators announce unQL. SQL for NoSQL  - buster
http://www.unqlspec.org/

======
antirez
As I said multiple times, in my humble opinion this is completely a useless
effort. There are two cases:

1) Two databases are semantically very similar. In such a case even if the
query language is different porting your application from one to another is
trivial, especially if you have a minimal layer of abstraction between your
program and you data, things like fetchUser(ID) or alike.

2) If the data model is different, using the same query language does not help
at all.

So the question is WHY? :)

~~~
Jach
A gazillion already-made programs (for example data visualization tools,
analytics software, etc.) speak only SQL. If the choice is between reinventing
the wheel for each NoSQL DB vs. using a SQL DB (such as <http://luciddb.org/>
[1] and soon postgres with their recent introduction of foreign data
wrappers[2]) as an intermediate layer or even a full data mart that does what
you want query-wise, a lot of people want to save time and just use the SQL
DB. (Why do you think Hive exists?) There's more to DBs than storing user data
for cat picture sharing sites...

[1] Disclaimer: I wrote a preliminary CouchDB connector for Lucid that'll get
released separately with the upcoming 0.9.4 release.

[2] I believe one of the first postgres foreign data wrappers was around
Twitter. So you move some API accessing code from an application layer that
realistically only your application can talk to, to the DB layer, and now
everything that can talk to the DB layer can access the data. (Unless they
want it raw, then they'll get it from Twitter.)

~~~
sitkack
In the same vein, I have been thinking about a mysql wrapper around various
nosql products.

Same issue, installed base and connectivity.

Composition, interfaces, abstraction.

------
martingordon
What's the point in adding an abstraction layer above NoSQL datastores when
most developers are already interacting with the datastore using another level
of abstraction (e.g., an ORM in their language/framework of choice)?

------
mark242
I'm at the CouchConf -- the demo of UnQL was fantastic.

The idea is that you shouldn't be locked into a NoSQL database, and that one
language that would work across all NoSQL databases will grow the community.
How each database manages their implementation of the spec is up to them.

INSERT into c1 value {"foo":1, "bar", ["a","b","c"]};

Now ignore the datastore behind that-- it could be Mongo, Couch, etc etc, but
you know that your query won't need to be rewritten in case you decide to
switch databases. This can only be a good thing.

------
Uchikoma
In 2009 I wrote in "The Dark Side of NoSQL" (1) about problems with NoSQL:

"1. ad hoc data fixing – either no query language available or no skills 2\.
ad hoc reporting – either no query language available or no in-house skills"

(1) <http://codemonkeyism.com/dark-side-nosql/>

------
henryprecheur
I don't know if I like it or not. If you know SQL well and want to switch to a
NoSQL database, what's easier learn? The "proprietary" API of the dababase
(like Redis, or MongoDB) or the limitations of unSQL?

I can't speak of other NoSQL databases, but unSQL doesn't seem to expose most
Redis' features, like lists & sets.

~~~
dpapathanasiou
_what's easier learn? The "proprietary" API of the dababase (like Redis, or
MongoDB) or the limitations of unSQL?_

That's what bothers me about this, too.

While I can understand the goal of making noSQL databases more accessible to
people who already know SQL, as well as the need to unify the commands across
all the different flavor of noSQL databases, there's something fundamentally
flawed about accessing unstructured data via logic intended for structured
data.

~~~
chewbranca
The data is not necessarily unstructured, it just doesn't have a strictly
inforced schema. So I'm very intrigued by this if they're adding it as a layer
on top of CouchDB views. If they are, you could use your views to selectively
filter on documents with a known structure, and then safely operate across a
subset of your docs with unql. We'll see where they go with this though.

~~~
chewbranca
To clarify for the downvoters, I'm talking about this in the context of
CouchDB, which I believe was a fair assumption to make seeing as Damien Katz
is one of the principle people involved and it was announced today at
CouchConf.

In CouchDB, running a filter on top of view results is something you can only
do in list functions or client side, so I am very curious to see how they
incorporate this into CouchDB.

------
jeffdavis
I'm kind of wondering, what next? An optimizer?

I think there's a lack of clarity on what's being reinvented here, why, and
where this is all headed. And when we get there, is it really something
fundamentally new, or is it something that existing SQL products can absorb
along the way?

------
TamDenholm
I know SQL moderately well, but does anyone share my view that moving AWAY
from using SQL syntax is a GOOD thing? I personally really dislike writing
SQL, i'm sure lots of other people do too, thats why people write query
builders etc.

~~~
buster
Actually i find SQL a great thing, and one thing that bothers me with all
those "other" databases is that you have to start from scratch with everyone
of them. A common Query language would be awesome!

------
Mpdreamz
Title is missleading. Nosql is an umbrella term for keyvalue-, document-,
object-, graph-, column- etcetera- databases. The API's these provide are
probably using a paradigm most natural to the actual habitat the data lives in
already. Is this "no sql for nosql" really a problem that needs solving or
merely a flakey abstraction thats super interesting to implement?

Unql seems to only focus on json based document stores so it might actually
make a decent abstraction.

Too easy to dismiss as impractical and i hope these guys pull off something
amqazing if only for json document stores.

~~~
buster
The title doesn't state that it's for every NoSQL database.

------
vertice
We've had great success with using ElasticSearch to index our couch db
databases in near realtime into it's lucene indexes, and then querying those.

It allows each tool to focus on what it does well.

~~~
jat850
Looking into something very similar right now. What's your tradeoff been in
terms of, for example, disk taken up by Elastic for indexing? How do you find
Elastic in terms of how well it keeps up with indexing the data recently
inserted into couch?

------
va_coder
It can't get much simpler than this can it?

Redis: redis.set "foo", "bar"; redis.get "foo"

Mongo: db.stuff.save({json: "object"}); db.stuff.find({json: "object"})

~~~
VladRussian
it will get simpler when your statement would look like :

Redis, Mongo, <insert your own zoo> ... : db.set(), db.find()

------
strmpnk
Uncle or Uncool. The hipster query language.

------
dpapathanasiou
It looks like a SQL syntax to access noSQL databases.

I'm not sure if that's a step forward or backward.

~~~
mrkurt
SQL is a fantastic set based language. Using SQL to query MongoDB would be
about 7 steps forward for just about everything I do, particularly if "SQL"
magically included joins.

~~~
Jach
Also would be cool if everything magically supported the 1-Bucket-Theta
algorithm. :) [http://www.ccs.neu.edu/home/mirek/papers/2011-SIGMOD-
Paralle...](http://www.ccs.neu.edu/home/mirek/papers/2011-SIGMOD-
ParallelJoins.pdf)

------
cmorrisrsg
It'll be interesting to see how much this gets adopted. Ad-hoc query languages
like SQL are great for operations and reporting, but if your NoSQL store needs
to conform to the limitations of the unQL language, aren't you losing that
"polyglot persistence" quality of using NoSQL?

------
kunley
I think the whole SQL vs NoSQL stuff is a bit mislead.

Relational databases are not dinosaurs. They solve lots of problems. It's the
database schema which is a PITA, so let's just have relational engine (with
reasoning, like Prolog) without the schema and move on.

Most people don't need NoSQL for scalability, they choose it because they
dislike SQL. So maybe it's SQL (as a syntax) we should ditch, together with
the schema thing, not the relational model as it is. In this context, the
effort with unQL, while being a remedy for some short-term situation, is
actually not so cool in the long term, because it will keep the legacy
undying.

------
Dysiode
In my ignorance I see "...an open query langauge for JSON..." and I think
"Cool. Now I'll be able to store complex database in plaintext." Am I wrong or
just missing the point?

I like the idea of SQLite but it would be nice to not have to jump through
hoops to access the databases of programs (I recall having some trouble with
Pidgin in the past that I gave up on because I was too much of a newb to know
how to interact with SQLite databases).

------
nivertech
Don't repeat the same mistakes as OQL[1]?

[1] <http://www.odbms.org/ODMG/OG/>

------
mark_l_watson
While my first thought is that I would rather use native APIs for each
datastore, I do use SPARQL and SQL a lot so there is some sense to a standard
query language.

The problem is having too abstract of an interface that does not allow easy
access to functionality of different datastores.

------
NHQ
Is that pronounced "uncle", or "uncool"?

~~~
bergie
SQL is pronounced as _sequel_ , so I'd definitely go with _uncool_. Even
though this actually can be quite cool.

Looking forward to explaining to a client that _yes, we just need to run this
one uncool query to get the report_ ;-)

~~~
ryeguy
SQL is not pronounced as "sequel". The ANSI standard declared that it is
pronounced S-Q-L.

<http://en.wikipedia.org/wiki/SQL#Standardization>

------
bergie
You could also claim that Sparql is already "a standard query language for
NoSQL"

<http://decentralyze.com/2010/03/09/rdf-meets-nosql/>

------
cdcarter
Anything that makes Couch more powerful is great! I'm interested to see how
they integrate this into the viewserver, it seems like it allows a bit more
expressibility than the current JS system does.

------
alecbenzer
unrelated to databases, but does anyone know how they made those charts for
the grammar? is there a tool for that (ie something that would generate those
charts automatically given a grammar).

~~~
jeffdavis
Those are called "railroad diagrams". I don't have a specific recommendation,
but this should get you started:

[http://stackoverflow.com/questions/773371/what-is-a-good-
too...](http://stackoverflow.com/questions/773371/what-is-a-good-tool-for-
creating-railroad-diagrams/)

------
ErikRogneby
It seems all of the examples are coming soon. Where is my friend SCOTT/TIGER?

------
igorgue
This deserves a XZibit meme.

~~~
5avage
Yo dawg, I heard you like NoSQL but missed yo SQL so I made UnQL for yo NoSQL.

~~~
mattadams
Eminem, is that you?

------
kermitthehermit
Ohh, the irony: NoSql - because SQL is bad and we thought of fixing it! Fast
forward some years into the future, current times - NoSql gets its, you
guessed it, SQL back.

Can someone help me stop laughing at this, please?

Nevermind, it looks like a waste of time.

~~~
alnayyir
Non-relational databases have nothing to do with SQL, they have to do with
trade-offs in data structures, consistency, availability, fault-tolerance, and
distribution.

You need to understand how ignorant you are, because until you do you're going
to have a calcified and incomplete understanding of databases.

~~~
kermitthehermit
Quite the opposite, I clearly recall some people from the NoSQL camp (read
non-relational data stores, non SQL enabled) saying that SQL itself is bad and
something else is needed.

I should have mentioned this before the zealots kicked in.

~~~
alnayyir
> I clearly recall some people from the NoSQL camp (read non-relational data
> stores, non SQL enabled) saying that SQL itself is bad and something else is
> needed

No, wrong, irrelevant, who said this?

~~~
kermitthehermit
I know it's wrong, you'll have to kill me to make me stop using SQL.

I wish I still had the article from 2009 - 2010 which said that SQL is too
difficult and other things like that.

Anyway, this is what I was talking about when I originally replied.

~~~
alnayyir
I'm fond of SQL, you're either intentionally misinterpreting me or I'm not
being clear. Non-relational databases are not about not using SQL, to believe
so is dense and willfully ignorant.

I asked for specifics, you didn't provide them. I have to assume you're a
troll at this point. I'm done here.

~~~
kermitthehermit
Ok, maybe I didn't use the right words or something: There was an article from
someone in the NoSQL camp which said that SQL is bad.

I DO and DID understand that the querying language isn't restricted to
relational databases.

What I was saying I REMEMBER reading something a while ago on the website of a
NoSQL store or in an article which said something along the lines: "SQL is old
and should be deprecated anyway, it was time for something new"

THAT was why I was amused.

If you think I was trolling or anything, ok, I'll just stop commenting on this
site. It's not worth the trouble at all.

This is my last comment.

edit: I think this was it: [http://gigaom.com/cloud/facebook-trapped-in-mysql-
fate-worse...](http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-
than-death/)

