Hacker News Reader

Comment by andrea_s | Hacker News Reader

Am I alone in thinking that sql-like syntax is actually a step backwards from building query documents programmatically (MongoDB style)?

View on HN

I'd say RethinkDB does it best. You just chain some regular function calls and pass some lambdas here and there. It looks and feels very natural. Plus, that "data explorer" thing lets you test those queries quickly.

Generating a list of all used tags:

  r.table('posts')('tags').reduce((a, b) => a.setUnion(b))

Grabbing all posts with the 'foo' tag:

  r.table('posts').filter((doc) => doc('tags').contains('foo'))

DocumentDB has a similar looking (maybe not as powerful) interface:

  context.collection.filter(function(doc) {
    return doc.city == "Melbourne" && doc.rating > 4.5;
  }).map(function(doc) {
    return doc.displayName;
  });

I've been a long time elasticsearch user and can say that I personally HATE sql syntax when it comes to querying data in mysql, just because I usually can't get the joins right etc to build a search that is reasonable. However, they might be taking this approach because sql syntax is familiar. JSON data structures for querying over HTTP was used with elasticsearch because they were familiar to most developers. I think overall it helps adoption if you have layers that are not completely foreign to the implementing developers. They could have written their query syntax in protocol buffers or coffescript or what ever the hell they wanted really, but I think that would have hurt adoption.

You can still build documents programmatically. The SQL-esque syntax is optional. The primary interface is HTTP.

Oh, I see, I've missed this detail on the first read. Thanks!

> The SQL-esque syntax is optional. The primary interface is HTTP.

Then the introduction needs some work.

"DocumentDB enables complex ad hoc queries using the SQL dialect"

"Azure DocumentDB offers the following key capabilities and benefits: Ad hoc queries with familiar SQL syntax"

The "Query DocumentDB" article also seems to be focused on that SQL dialect.

Not necessarily.

I would say it allows flexibility in thinking about your storage and access patterns, which in turn allows flexibility in use. Hopefully without the expense of performance, and integrity.

how? you're just doing the same thing with MongoDB in their own json-like syntax instead of the T-SQL that everyone knows

For simple queries there is virtually no difference (and clearly one should favor what he knows best).

But there are cases where you need to build the query object programmatically (and dynamically), and I believe it's a bit awkward to do that to obtain an SQL statement. But possibly it's just my personal taste :)

yes

Reply on news.ycombinator.com