Regarding chaining, I’ve seen that MongoDB supports queries of a certain complexity. But as far as I can see, the complexity is primarily restricted to AND clauses. I haven’t seen an example of OR in the MondoDB docs (though maybe just throwing multiple queries is the best way).

On your comment about joins - I see your point. In the end, given that NoSQL does away with RDBMS semantics such as normalization, it seems that duplication is acceptable (even preferred?). However, even with duplication, it seems that you still have define duplicate entities a priori, rather than on the fly.

Good point about non-relational thinking when working with these systems

First, with regard to complex queries, the mongoid ruby library is very good (mongoid.org). It uses a DSL called Criteria, which allows method chaining. To use one of their examples, queries like “Person.only(:first_name).where(”phones.country_code” => 1).in(:last_name => ["Vicious"])”. Perhaps python has similar.

With regard to joins, the question is always whether to embed related data inside a document (as an array/hash-type structure), or link to it in a separate collection. The MongoDB website has quite a lot of discussion on this topic. You might, for example, store the IDs from one collection in an array in another collection as a quick way to join the two.

I agree with your point about just “dumping” data, as opposed to requiring some schema for queries. I find the nice thing about MongoDB is that you can dump first, then think about it later. So you can inspect the atrributes of an object, decide which ones look useful, index them and add them to the object model as you see fit. Again, I find that the ruby mappers (mongomapper and mongoid) work very well for this.

I find the map-reduce barrier quite high too. Some of the libraries let you write queries (e.g. the basic ruby mongo driver has a map_reduce method), but you still have to write in javascript. Perhaps someone will come up with a DSL, a bit like RJS in Rails which allows queries in the native syntax of your language of choice.

I think the most important thing when starting out is to stop thinking in a RDBMS way. MongoDB is maybe more confusing than others because it has relational-like aspects, but I find it’s best to ignore them and concentrate on good document design.

1.) Most off the shelf reporting tools expect an SQL interface. Period.

2.) While key-value stores and the like can compete or outrun RDBMS in straight searches or transactions, I wonder what happens when you need complex joins, projections?

It’s all raw power and no finesse. Often raw power is just enough. But often you need some finesse also.

At the moment I can say that it works as expected at least with smaller datasets (~20000 structures), is easier to program (only Java, no SQL) and a lot (10x-100x) faster when searching.

The main drawback is that you need enough memory to keep all your business objects in RAM and must implements efficient query strategies yourself. No optimizer will help you in Prevaylerland.

Point taken, you’re absolutely right.

But you can still generate ORA-600s with careless code in the extproc listener or pollute the query cache with broken prepared statements - which technically does not crash the server but still renders it unusable.