4 ms·

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 suc

by antirez 15y ago

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 15y ago
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/ 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 ago
  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.
yawniek 15y ago
that 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.
- arockwell 15y ago
  SPARQL is substantially less powerful than SQL. No delete/update/insert statements, no subselects, and limited aggregation and functions. I've used SPARQL a lot in the past year and I am constantly running into limitations. 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.
  - yawniek 15y ago
    well there are efforts for updates etc. but yes, you have limitations with sparql, thats why i think it is not the final solution. but it is a first approach to push the possibility to query data to a different layer.
thesorrow 15y ago
Obviously the only good thing is for developers who are not familiar with noSQL technologies. This is a nice try to unify the model language. Unfortunately, the additional load generated by the query parsing is a no go for me.
mmalone 15y ago
The argument in the article that inspired this work[1] (and it may be an academic one) is that data models are all semantically very similar. The authors argue that category theory provides mathematical formalism for a generic abstraction that would bridge both the relational and K/V worlds. 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-model-of-data-for-large-shared-data-banks/fulltext http://cacm.acm.org/magazines/2011/4/106584-a-co-relational-...

by antirez 15y ago

Jach 15y ago

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/ 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 ago
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.

yawniek 15y ago

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

arockwell 15y ago
SPARQL is substantially less powerful than SQL. No delete/update/insert statements, no subselects, and limited aggregation and functions. I've used SPARQL a lot in the past year and I am constantly running into limitations. 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.
- yawniek 15y ago
  well there are efforts for updates etc. but yes, you have limitations with sparql, thats why i think it is not the final solution. but it is a first approach to push the possibility to query data to a different layer.

thesorrow 15y ago

Obviously the only good thing is for developers who are not familiar with noSQL technologies. This is a nice try to unify the model language. Unfortunately, the additional load generated by the query parsing is a no go for me.

mmalone 15y ago

The argument in the article that inspired this work[1] (and it may be an academic one) is that data models are all semantically very similar. The authors argue that category theory provides mathematical formalism for a generic abstraction that would bridge both the relational and K/V worlds. 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-model-of-data-for-large-shared-data-banks/fulltext http://cacm.acm.org/magazines/2011/4/106584-a-co-relational-...