3 ms·

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

haxor1232123 12y ago
yes
balls187 12y ago
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.
luuio 12y ago
how? you're just doing the same thing with MongoDB in their own json-like syntax instead of the T-SQL that everyone knows
- andrea_s 12y ago
  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 :)
reubenbond 12y ago
You can still build documents programmatically. The SQL-esque syntax is optional. The primary interface is HTTP.
- andrea_s 12y ago
  Oh, I see, I've missed this detail on the first read. Thanks!
- ahoge 12y ago
  > 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.
johnnymonster 12y ago
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.
ahoge 12y ago
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'))
- reubenbond 12y ago
  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; });

haxor1232123 12y ago

yes

balls187 12y ago

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.

luuio 12y ago

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

andrea_s 12y ago
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 :)

reubenbond 12y ago

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

andrea_s 12y ago
Oh, I see, I've missed this detail on the first read. Thanks!
ahoge 12y ago
> 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.

johnnymonster 12y ago

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.

ahoge 12y ago

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'))

reubenbond 12y ago
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; });