21–30 of 61 posts
I've been through the hassle of programatically piecing together complex SQL queries, and I'd far rather be able to just put together hashes that represent my query. SQL was originally designed so that people who were savvy but not necessarily developers were able to query databases, but I can't think of the last time my boss would have wanted to run some random query against our production database.
There is always http://querymongo.com/ which will convert SQL to a MongoDB query.
I actually dislike this tool a fair bit, because it gets people to continue thinking of Mongo as "Mysql plus WEB SCALE" or whatever. It's a totally different database and doesn't do well with highly-normalized relational-style data, and the idea of an "automated converter" seems to reinforce the idea that it's just a drop in for MySQL that automatically solves all your scaling woes, when that's just utterly and compl…
Also that might be one thing it does but it also allows people to transition from SQL queries they know to mongodb queries. It helps the learning process.
It does a lot of things better than SQL, too. Consider, for example, the query "Give me a list of all posts with all of these tags, by any of these authors, sorted by post date descending"
db.posts.find({
tags: {$all: ["foo", "bar", "baz"]},
author: {$in: ["Joe", "Jane"]}
}).sort({post_date: -1})
SELECT posts.* FROM posts
INNER JOIN post_tags t1 ON t1.tag = "foo" AND t1.post_id = posts.id
INNER JOIN post_tags t2 ON t2.tag = "bar" AND t2.post_id = posts.id
INNER JOIN post_tags t3 ON t3.tag = "baz" AND t3.post_id = posts.id
WHERE posts.author = "Joe" or post.author = "Jane"
ORDER BY post_date DESC;
Earlier quoted context omitted.
I actually dislike this tool a fair bit, because it gets people to continue thinking of Mongo as "Mysql plus WEB SCALE" or whatever. It's a totally different database and doesn't do well with highly-normalized relational-style data, and the idea of an "automated converter" seems to reinforce the idea that it's just a drop in for MySQL that automatically solves all your scaling woes, when that's just utterly and compl…
You mean SQL not MySQL. Also that might be one thing it does but it also allows people to transition from SQL queries they know to mongodb queries. It helps the learning process.
I fully support it as a learning tool, but Mongo's query language isn't all that hard to pick up if you already know how SQL works. Getting stuck into the mindset of "just write relational DB-oriented software and then generate some Mongo queries for it" is an awful practice that is sure to lead to much pain and suffering.
Here's what this query looks like in RethinkDB (also based on JSON documents): r.table('orders') .pluck('cust_id','ord_date','price') .groupBy('cust_id','ord_date', r.sum('price')). .filter(r.row('reduction').gt(250)) We use the hard-coded attribute 'reduction' because groupBy automatically gets compiled to our distributed map-reduce infrastructure. There is currently no as command (though it could easily be simulate…
Under the same effect I'm not a fan of mongo style query({}).limit(count).skip(num) format and usually I move the limit and skip into the initial query.
Here's what this query looks like in RethinkDB (also based on JSON documents): r.table('orders') .pluck('cust_id','ord_date','price') .groupBy('cust_id','ord_date', r.sum('price')). .filter(r.row('reduction').gt(250)) We use the hard-coded attribute 'reduction' because groupBy automatically gets compiled to our distributed map-reduce infrastructure. There is currently no as command (though it could easily be simulate…
Its not an abuse of JSON to use it as a way of representing queries, but its probably a shame that Mongo haven't provided a better way of generating queries.
You picked an ugly mongo query, and there are many. You compared it to a concise SQL query, and there are many that are not. MongoDB's limit(x) and skip(y) are a shitload nicer than most of Microsoft's ideas about pagination. It was only in SQL Server 2012 that they came up with "OFFSET" instead of "google it".... http://stackoverflow.com/questions/2244322/how-to-do-paginat...
Here's what this query looks like in RethinkDB (also based on JSON documents): r.table('orders') .pluck('cust_id','ord_date','price') .groupBy('cust_id','ord_date', r.sum('price')). .filter(r.row('reduction').gt(250)) We use the hard-coded attribute 'reduction' because groupBy automatically gets compiled to our distributed map-reduce infrastructure. There is currently no as command (though it could easily be simulate…
After seeing the screencast of RethinkDB it seems to me that it's just like Mongo but a much better API and easier handling of sharding and replication. The only con I see of using RethinkDB is that it's very new (so is Mongo...) and probably is little too early for production. Basically I hope not to find worse surprises down the road than I hear of Mongo :P
I've been through the hassle of programatically piecing together complex SQL queries, and I'd far rather be able to just put together hashes that represent my query. SQL was originally designed so that people who were savvy but not necessarily developers were able to query databases, but I can't think of the last time my boss would have wanted to run some random query against our production database.