Warning: Only my opinion too :-) .
In madIS, we ended up faking some of the features that document based
databases have. Without these features, it would be extremely hard to
build queries that describe advanced processing workflows.
The main features that we ended up faking are:
- JSON "packs" (or jpacks in madIS), which are in essence JSON lists
that contain many values. The main difference between madIS's jpacks and
regular JSON lists is that a jpack(base_type) = base_type . Examples:
select jpack(1) as C;
C
--------
1
select jpack(1,2) as C;
C
--------
[1,2]
- Nested tables, without which SQL is severely deficient in describing
any advanced processing. Example:
select jsplit("[1,2]");
C1 | C2
-----------
1 | 2
- Virtual tables having queries as parameters.
select * from (XMLPARSE select "<a><b>row1val1</b><b>row1val1b</b></a>");
{"a/b":"row1val1"}
{"a/b":"row1val1b"}
From my standpoint, UnQL is a very nice first try towards solving above
DB deficiencies. It would be a shame if this effort is abandoned.
Concerning the other query languages. Cassandra's SQL inspired queries
are very limiting. There is a company that merged Cassandra with
Hadoop/Hive, providing Cassandra with more advanced querying abilities,
but the last time a looked at it, it wasn't working so well.
Riak and a number of other key-value stores that do not have rich query
interfaces are useful only for OLTP workloads and do not cover OLAP
workloads at all.
I don't like MongoDB's approach very much. It seems to me that
extending/expanding SQL to cover MongoDB's use cases would be a better
solution than starting from JSON and working towards SQL. While i like
JSON very much, whenever i needed to do a MongoDB query i had to
translate from SQL to MongoDB through the use of a translation table.
For better or worse, SQL is the de facto lingua franca of query languages.
IMHO, UnQL has a lot of promise in expanding SQL into domains that right
now are served poorly from existing querying solutions.
l.
On 11/12/12 05:28, Roger Binns wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/12/12 19:01, dcharno wrote:
What ever happened to Unql and is there any chance it will be revived?
It seemed like it would have been incredible useful.
Warning: My opinion only
Unql seemed to be especially pointless. Being somewhat compatible with
SQL syntax made no sense - SQL syntax and all the tools using it assume
the relational model and simple table like data layouts. NoSQL databases
vary, but generally they are non-relational and schemaless, and JSON
interoperable ones have a structure completely different than SQL tables
(eg item nesting).
Every NoSQL database already has its own query mechanism so Unql would
always be a second class citizen if any of them ever adopted Unql.
NoSQL databases also tend to have looser consistency, have multiple
servers available and various other semantics very different than SQL
servers. The native NoSQL interfaces expose and work with those semantics.
Cassandra did actually end up with something SQL inspired:
http://cassandra.apache.org/doc/cql/CQL.html
Riak uses something like Google advanced searches (field:value):
http://docs.basho.com/riak/latest/cookbooks/Riak-Search---Querying/
MongoDB uses JSON with extra magic operators:
http://docs.mongodb.org/manual/applications/read/
Personally I like MongoDB approach where queries strongly resemble the
underlying stored data which means very little translation between the two.
Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlDGqEAACgkQmOOfHg372QQ8OACgxbOBcp1F5rADh9Uw5+0efsEe
5RQAn3sim96zcz6x2lKMXF+B7Sp20P1A
=OHFc
-----END PGP SIGNATURE-----
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
