Oh I really like working with a NoSql store. It makes a lot of things a lot easier in certain situations. If you have mostly transactional data that can truly be self-contained it's much faster than SQL and much easier from the programming layer to interact with. I have a few applications running on Mongo and it's very easy to work with as long as you don't need to do a lot of reporting and cross document querying.

I used it with .NET. One app is a survey app that deals with a ton of surveys entered by users. In a relational app you'd break these things into a ton of separate tables with NoSql each survey is its own document and fully self contained. So what would have probably been 15-20 tables ended up being a single document store.

Again - I wouldn't use it for everything, but it lends itself to certain scenarios especially mostly input scenarios. Not so good for heavy/dynamic query scenarios.

+++ Rick ---

>>The backups hold all the sites, my SQL backup folder (from nightly backups), my MongoDb backups.
>
>Nozy me again - if you feel talkative ;-)
>Why / what for do you use MongoDB ?
>I know it is a real breeze for any JS backend to connect to and due to JS "reactivity-easy" nature was chosen as backend for very first Meteor steps, but that was also the thing turning me off early Meteor. The "DB everywhere" and "only data wired" principles felt soooo correct, only to find out later, that SQL data was less than an ugly step child and bulk of effort went into the Mini-Mongo client side "caching engine/database", which I consider to be superior architecture minimizing costly server lookups but want for SQL backends...
>
>regards
>
>thomas