I don't think I would quite agree with that.. I would say that mongo is very accessible in terms of getting started... also, you can index nested properties via dot notation, unless you are really deeply denormalized, collections of objects with collections, I haven't been aware of any issues there.

A few things that surprised me about mongo... first that if you do a sort, you either need an index on your sorting fields or your sort info needs to fit in 32mb. I'm using skip/limit for paging, and it really became an issue once I was running against the full datastore. Second, only one single index is used in a query, unike most sql databases that will collate results of mutiple indexes under the covers... this caused me to rethink my index strategy, as well as add both asc/desc indexes for sorting results.

For me it was a matter of getting away from an over normalized data set (30+ queries for a single vehicle classified ad display, 23-joins if you wanted to reduce 15 of those queries (my main VIEW created for migration)... denormalized data makes more sense for this use case. For others it may or may not make sense.

Relational systems use multiple indexes for queries, though I'm not aware of an implementation that uses multiple indexes for a single table.

Remembering that a query in Mongo is basically a query on a single table it's acting in the same way a relational db does - ie, check statistics, choose best index, perform lookups.

Could you give examples? I'm working at a company where Mongo is being used because.

once you get into creating administrative/reports sections i think you'll quickly find out.

what does PHP "drops" in the name of getting started quickly ? PHP is now a robust language with robusts frameworks like SF or ZF.

Two examples: including loads of functionality into the default namespace instead of developing it as external libraries, and confusing the template language and the programming language which encourages XSS vulnerabilities in PHP written by beginners. When using PHP you normally want to use a different template language to avoid having to audit the code and hunt unescaped output.

Is there a real practical difference beween "strlen($str)" and "string::length($str)"? It may be a design decision that you disagree with, but it hardly gets in your way. It's certainly not "dropped" functionality. It also ends up being faster, as the core functionality is written in C rather than in userland PHP code.

I agree with your point about XSS, but I've seen XSS exploits in every language, so I can hardly consider it a PHP flaw. It's also literally a one-line config change to eliminate that problem[1]; the only reason that's not the default is that it would break lots of existing apps the next time they upgraded. Then again, that's also true for the wacky (err, copied from C) naming conventions.

[1] Unless you go out of your way, of course. But that's true with anything where you can decode html entities. For the record, the config change is "filter.default=full_special_chars" which will automatically sanitize all user input (GET, POST, COOKIE, SERVER) with htmlspecialchars.

1) It is not the namespaces per se. It is the inclusion of everything and the kitchen sink in the standard library which discouraged the development of a healthy third party library community. Contrast with Perl and Ruby where there are third party libraries for virtually everything despite them being less popular languages.

2) filter.default is not a correct solution. You should escape output, not input. Escaping input 1) results in crap data in your database 2) opens you up for user input sources you forgot about. What if for example you have another application working against the same database? One which is not web based?

The existence of filter.default is an example of the very problem with PHP. It works for simple CRUD applications but when you application grows reliance of it is almost guaranteed to create an XSS vulnerability.