For a large part it's a decision on when you want to receive the pain.
I am in favor of (mostly) strict schemas. From my experience thinking really good about your domain models before you start implementing really pays off. When you have a good domain model, the database schemas follow from it, and so does the consistent business logic.
Figuring out the domain model is tricky. That's why you use prototype (which you throw away, and not use as basis for your production system). During the prototype phase you can opt for a schema-less solution to more rapidly explore how your domain model should look like.
For a large part it's a decision on when you want to receive the pain.
I am in favor of (mostly) strict schemas. From my experience thinking really good about your domain models before you start implementing really pays off. When you have a good domain model, the database schemas follow from it, and so does the consistent business logic.
Figuring out the domain model is tricky. That's why you use prototype (which you throw away, and not use as basis for your production system). During the prototype phase you can opt for a schema-less solution to more rapidly explore how your domain model should look like.
Valid points Michiel, "thinking really good about your domain models" is key.
Have you played around with dynamic schema's at all?