4 ms·

I got downvoted awfully last night for trying to say this, but I'll say it again to back you up: Developing with mongodb is _lightning fast_ and holds up very

I got downvoted awfully last night for trying to say this, but I'll say it again to back you up: Developing with mongodb is _lightning fast_ and holds up very very well. If you end up with problems, switch to SQL later! I don't think a lot of these people hating on the nosql projects have actually tried building something with them.

simonw 17y ago
I dunno... I find the combination of the Django ORM and South (in particular the --auto flag for auto-creating migrations) is incredibly productive. With the ORM, I can conjure up a query that answers pretty much any question I might have of my data. I've experimented with MongoDB (and a bunch with Redis) and I find I'm much more likely to end up with a query that I can't resolve without having to do a bunch of extra work. Most of this is probably having expertise with the tools, but I find that for rapid prototyping the ability to run relational queries is really important, especially since query performance during the prototyping phase isn't really an issue.
- paulgb 17y ago
  I've found that relational ORMs force me to write convoluted and weird code for all but the simplest of joins. Maybe django's ORM is better; I've mostly used SQLAlchemy and a few others.
  - rbanffy 17y ago
    You know that you can use SQL with Django, if you have an insanely convoluted join.
richcollins 17y ago
Why is it faster?
- paulgb 17y ago
  It doesn't force you to fit non-tabular (eg. hierarchical) data into a table structure. Also, no schema means the data structure is more malleable. With the right ORM, this fits in well nicely with polymorphism: I can store objects with some common features in the same collection, but when I retrieve them from the database I get different types of objects which inherit the same base object. mongoengine is one ORM that does this.
  - heresy 17y ago
    Nice. But I have a difficult time seeing how storing "malleable" data like that, opaque to the storage engine, is going to be performant for querying. Must be nice to have requirements that never change once you've decided on a data representation...
    - paulgb 17y ago
      The database is still aware of the fields, so MongoDB can build indices on certain fields if you wish. Admittedly I haven't deployed Mongo in an environment that really tested its performance, but we've been serving about 20k pageviews per day with no issues. Granted, this was a fairly basic application. As for changing requirements, mongo handled those well too. It's certainly not a silver bullet, but when I just need a basic object store the query performance trade-off is worth it.
  - richcollins 17y ago
    Does MongoDB manage indexes for you?
- japherwocky 17y ago
  you don't even have to think about schemas or SQL, you can focus completely in whatever your language of choice is.
codexon 17y ago
Switching back and forth between Mongo and SQL is not without technical cost. The syntax and semantics are quite different and translating complex queries to map/reduce is also a problem.
mikebo 17y ago
I agree that developing with MongoDB is really really nice. We'll see how it holds up under more load, but for prototyping data models I have not used a better stack than mongodb + mongomapper

simonw 17y ago

I dunno... I find the combination of the Django ORM and South (in particular the --auto flag for auto-creating migrations) is incredibly productive. With the ORM, I can conjure up a query that answers pretty much any question I might have of my data. I've experimented with MongoDB (and a bunch with Redis) and I find I'm much more likely to end up with a query that I can't resolve without having to do a bunch of extra work. Most of this is probably having expertise with the tools, but I find that for rapid prototyping the ability to run relational queries is really important, especially since query performance during the prototyping phase isn't really an issue.

paulgb 17y ago
I've found that relational ORMs force me to write convoluted and weird code for all but the simplest of joins. Maybe django's ORM is better; I've mostly used SQLAlchemy and a few others.
- rbanffy 17y ago
  You know that you can use SQL with Django, if you have an insanely convoluted join.

richcollins 17y ago

Why is it faster?

paulgb 17y ago
It doesn't force you to fit non-tabular (eg. hierarchical) data into a table structure. Also, no schema means the data structure is more malleable. With the right ORM, this fits in well nicely with polymorphism: I can store objects with some common features in the same collection, but when I retrieve them from the database I get different types of objects which inherit the same base object. mongoengine is one ORM that does this.
- heresy 17y ago
  Nice. But I have a difficult time seeing how storing "malleable" data like that, opaque to the storage engine, is going to be performant for querying. Must be nice to have requirements that never change once you've decided on a data representation...
  - paulgb 17y ago
    The database is still aware of the fields, so MongoDB can build indices on certain fields if you wish. Admittedly I haven't deployed Mongo in an environment that really tested its performance, but we've been serving about 20k pageviews per day with no issues. Granted, this was a fairly basic application. As for changing requirements, mongo handled those well too. It's certainly not a silver bullet, but when I just need a basic object store the query performance trade-off is worth it.
- richcollins 17y ago
  Does MongoDB manage indexes for you?
japherwocky 17y ago
you don't even have to think about schemas or SQL, you can focus completely in whatever your language of choice is.

codexon 17y ago

Switching back and forth between Mongo and SQL is not without technical cost. The syntax and semantics are quite different and translating complex queries to map/reduce is also a problem.

mikebo 17y ago

I agree that developing with MongoDB is really really nice. We'll see how it holds up under more load, but for prototyping data models I have not used a better stack than mongodb + mongomapper