Started using MongoDB + Mongoid a few weeks ago. I have no plans to ever use MySQL/PostgreSQL for any projects ever again (unless they have requirements MongoDB can't meet).
Prototyping without database migrations is amazing.
MongoDB is good, and Mongoid has a lot of features. However, I ran into a few Mongoid bugs that bothered me and I am transitioning my project to PostgreSQL.
Part of that is because my boss added a lot of features to the project that are easier to implement with normalized data. I could write JavaScript map/reduce functions to handle some of the cases, but using ActiveRecord 3.1 will be easier for me and easier for the next guy to maintain.
Everyone should try Mongoid out to learn its strengths. I agree with Ilya Grigorik when he says 90+% of the time SQL remains the most practical solution for the problem at hand (paraphrased).
You can use your regular normalization tactics (has_many, belongs_to, has_many_and_belongs_to_many, etc.) with MongoDB, too. You could treat it like a MySQL/PostgreSQL that simply allows arbitrarily nested/embedded documents if you need them. The flexibility is great. Check the video I linked.
And, no, SQL is not awesome. It's painful and not implemented the same way everywhere. Fortunately, we don't really have to write too much of it nowadays.
Comments
Started using MongoDB + Mongoid a few weeks ago. I have no plans to ever use MySQL/PostgreSQL for any projects ever again (unless they have requirements MongoDB can't meet).
Prototyping without database migrations is amazing.
This video on MongoDB-style schema design was extremely helpful: http://blip.tv/mongodb/schema-design-with-mongodb-3723187
MongoDB is good, and Mongoid has a lot of features. However, I ran into a few Mongoid bugs that bothered me and I am transitioning my project to PostgreSQL.
Part of that is because my boss added a lot of features to the project that are easier to implement with normalized data. I could write JavaScript map/reduce functions to handle some of the cases, but using ActiveRecord 3.1 will be easier for me and easier for the next guy to maintain.
Everyone should try Mongoid out to learn its strengths. I agree with Ilya Grigorik when he says 90+% of the time SQL remains the most practical solution for the problem at hand (paraphrased).
I disagree
Prototyping without database migrations is amazing.
Prototyping with normalization and fast joins is amazing as well, SQL's awesome!
You can use your regular normalization tactics (has_many, belongs_to, has_many_and_belongs_to_many, etc.) with MongoDB, too. You could treat it like a MySQL/PostgreSQL that simply allows arbitrarily nested/embedded documents if you need them. The flexibility is great. Check the video I linked.
And, no, SQL is not awesome. It's painful and not implemented the same way everywhere. Fortunately, we don't really have to write too much of it nowadays.