Imagine you want to write a webapp for selling your car online.
A car has a lot of attributes. Like how many doors, color, aircondition, etc. Some of them are simple boolean values, others might need to store more information (number of doors).
Some Accounts will become upgraded to "re/taider" accounts and they will have the possibility to sell more then one car.
From what I learned at school this actually screams for a relational database model.
But I would really like to get into NoSQL.
Would it be very silly to use Mongodb or Couchdb in this case?
Here is a more specific question, which exceeds my understanding and might give you a clue of my thinking.
A car has many attributes and you want to search for a car with as many attributes you like.
Now the only way I know how to handle this in NoSQL is to have a lot of Map-reduced views.
However, with only 12 attributes there is a possibility of 4096 different combinations. One can not do 4096 map-reduces for this use case. It can't be the common way, I mean it does not feel right.
Best Answer
Given that you say you believe this data model screams "relational" the thought that comes to mind is, "I have a nail and I would really like to use a crescent wrench.... Can you? Yes. Are you aware of the tradeoffs? Doubtful."
The basic point about NoSQL is that it makes sense when your data use cases are fairly simple and you have encapsulated that behind a full-featured API. The example I give for an area where NoSQL would generally be very good would be the backplane of an LDAP directory forest.
For the application you mention your big issue is likely to be flexibility in reporting. You would have to purpose build your reports in advance and that's the major cost. For an application like this, that is a very big cost.
One other point I would make is that you may find that there are opportunities to use NoSQL along side the RDBMS. For example you could implement a caching system for the web app using it.