9 ms·
Sqlite and couchdb creators announce unQL. SQL for NoSQL
- dpapathanasiou 15y agoIt looks like a SQL syntax to access noSQL databases. I'm not sure if that's a step forward or backward.
- megaman821 15y agoI think it makes a lot of sense for the document databases. It would make much less sense applied to something like Redis though.
- glassx 15y agoYeah... Redis could probably use a subset of SQL, though, but I don't know if it would be practical.
- mrkurt 15y agoSQL 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 15y agoAlso would be cool if everything magically supported the 1-Bucket-Theta algorithm. :) http://www.ccs.neu.edu/home/mirek/papers/2011-SIGMOD-ParallelJoins.pdf http://www.ccs.neu.edu/home/mirek/papers/2011-SIGMOD-Paralle...
- sad 15y agoI'd say forward for sure. This breaks down the barriers to entry for a lot of folks, especially in enterprise land. Definitely looking forward to how this develops.
- Uchikoma 15y agoIn 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/ http://codemonkeyism.com/dark-side-nosql/
- henryprecheur 15y agoI 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 15y agowhat'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.
- deleted 15y ago[deleted]
- leef 15y agoThe data is not unstructured, though. It is in JSON format which can be taken advantage of.
- chewbranca 15y agoThe 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 15y agoTo 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.
- vertice 15y agoWe'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.
- r00fus 15y agoI would be greatly interested in finding out more... what problems did you run into? Where did you spend most of the time?
- jat850 15y agoLooking 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?
- igorgue 15y agoThis deserves a XZibit meme.
- cmorrisrsg 15y agoIt'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?
- Mpdreamz 15y agoTitle 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 15y agoThe title doesn't state that it's for every NoSQL database.
- martingordon 15y agoWhat'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)?
- ErikRogneby 15y agoIt seems all of the examples are coming soon. Where is my friend SCOTT/TIGER?
- va_coder 15y agoIt 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 15y agoit will get simpler when your statement would look like : Redis, Mongo, <insert your own zoo> ... : db.set(), db.find()
- alecbenzer 15y agounrelated 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 15y agoThose 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-tool-for-creating-railroad-diagrams/ http://stackoverflow.com/questions/773371/what-is-a-good-too...
- TamDenholm 15y agoI 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.
- xi 15y agoYou might be interested in a project I've been working on lately: http://htsql.org/ http://htsql.org/ -- it's a high-level query language that compiles into SQL. The syntax was motivated by URLs and XPath; the semantics is based on navigational model. As opposed to many other non-SQL query languages, it supports analytical queries including aggregates and projections.
- buster 15y agoActually 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!
- ojosilva 15y agoI'm now a user of both MongoDB and SQL-based ORMs, and I find that using a No-SQL type syntax makes it much easier to work with data programatically, ie, turn a UI query into a db query. 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.
- jeffdavis 15y agoI'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?
- nivertech 15y agoDon't repeat the same mistakes as OQL[1]? [1] http://www.odbms.org/ODMG/OG/ http://www.odbms.org/ODMG/OG/
- antirez 15y agoAs 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 15y agoA 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/ 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 15y agoIn the same vein, I have been thinking about a mysql wrapper around various nosql products. Same issue, installed base and connectivity. Composition, interfaces, abstraction.
- yawniek 15y agothat is why i think that the "universal query languange" should be on a different layer. SPARQL is one answer to this very complex problem. something similar to sparql with map/reduce style distributed algorithms embedded could be an interesting approach.
- strmpnk 15y agoUncle or Uncool. The hipster query language.
- NHQ 15y agoIs that pronounced "uncle", or "uncool"?
- bergie 15y agoSQL 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 15y agoSQL is not pronounced as "sequel". The ANSI standard declared that it is pronounced S-Q-L. http://en.wikipedia.org/wiki/SQL#Standardization http://en.wikipedia.org/wiki/SQL#Standardization
- buster 15y agoit's pronounced uncle
- rhubarbquid 15y agoYeah, they pronounced it "uncle" at the CouchConf presentation.
- bergie 15y agoYou could also claim that Sparql is already "a standard query language for NoSQL" http://decentralyze.com/2010/03/09/rdf-meets-nosql/ http://decentralyze.com/2010/03/09/rdf-meets-nosql/
- cdcarter 15y agoAnything 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.
- Dysiode 15y agoIn 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).
- kermitthehermit 15y agoOhh, 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 15y agoNon-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 15y agoQuite 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 15y ago> 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 15y agoI 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 15y ago
- mark242 15y agoI'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.
- mark_l_watson 15y agoWhile 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.
- kunley 15y agoI 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.