Sqlite and couchdb creators announce unQL. SQL for NoSQL
unqlspec.org
unqlspec.org
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? :)
[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.)
Same issue, installed base and connectivity.
Composition, interfaces, abstraction.
Performance has also been very poor (we use Jena SDB). I don't know if poor performance is an implementation problem or an overall weakness.
The ideas all seem very formative to me. There are a bunch of assumptions, logic gaps, etc. But it's not all bad.
[1] http://cacm.acm.org/magazines/2011/4/106584-a-co-relational-...
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.
"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"
I can't speak of other NoSQL databases, but unSQL doesn't seem to expose most Redis' features, like lists & sets.
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.
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.
But let me interrupt your propaganda. We wouldn't want to address the reality that not all data and work sets can fit well in a relational database.
Example: http://blog.zawodny.com/2010/05/22/mongodb-early-impressions...
There was a presentation up here a few months ago on how the guys at http://wordsquared.com/ used MongoDB; they basically made the choice since they knew it already, instead of using postgres with their great geo libraries. And that's fine. What's stupid is when people who know one or the other pretty well spend a lot of time learning about the other for a use case that's most likely not really necessary anyway, or their current choice could handle with tweaks.
Of course, once public CS starts moving forward into innovative big analytics rather than just managing big data storage (such as the theta-join paper I linked elsewhere on this page), things may start shifting in favor of one of the NoSQL systems and the above quote would be equally suitable when comparing the Hadoop ecosystem or Mongo with some fancy new relational DB.
It doesn't.
It expresses some useful things about trade-offs but they aren't necessarily binary properties and it doesn't say anything about the underlying data structures or features of a database.
> then a lot of people don't need all that scalability. (And if it did, you'd use Hadoop anyway. =P
Maybe, not necessarily.
The backend should be chosen because of the data characteristics, not because of someone's experience..
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?
But as a human, say when I'm using the Mongo client, I miss using the much readable SQL. Typing JSON queries can be quite painful. And driving it thru a map-reduce javascript function just to summarize a column is horrendous.
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.
It allows each tool to focus on what it does well.
Redis: redis.set "foo", "bar"; redis.get "foo"
Mongo: db.stuff.save({json: "object"}); db.stuff.find({json: "object"})
Redis, Mongo, <insert your own zoo> ... : db.set(), db.find()
I'm not sure if that's a step forward or backward.
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.
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).
Looking forward to explaining to a client that yes, we just need to run this one uncool query to get the report ;-)
The problem is having too abstract of an interface that does not allow easy access to functionality of different datastores.
http://stackoverflow.com/questions/773371/what-is-a-good-too...
Can someone help me stop laughing at this, please?
Nevermind, it looks like a waste of time.
You need to understand how ignorant you are, because until you do you're going to have a calcified and incomplete understanding of databases.
I should have mentioned this before the zealots kicked in.
No, wrong, irrelevant, who said this?
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.
I asked for specifics, you didn't provide them. I have to assume you're a troll at this point. I'm done here.
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...