3 ms·
Really, the #1 reason to use MongoDB (if you're me, anyway) is to save development time associated with making your relational schema start small and change as
by mrkurt 16y ago
Really, the #1 reason to use MongoDB (if you're me, anyway) is to save development time associated with making your relational schema start small and change as your new app progresses. I feel a smug sense of joy every time I add a field somewhere, or delete another, or create some kind of nested document. It's taken me a while to really understand how many compromises I used to make because changing schemas is a pain in the ass.
Simplified queries, though, are a knock against mongo. Joins are great and I would like to do joins on my Mongo documents, but I end up having to replicate a lot of that in code. Sure it's nice that a document can be more complex and you don't spend a lot of time moving things into tables that are really part of the same record. It's nice because it's not forced, though, not because keeping data in different tables is always the wrong way to do things.
- weixiyen 16y agoA lot sites these days don't do joins with relational databases anyways. They just use mysql or postgresql as a key value store.
- saurik 16y agoI use PostgreSQL and change my schema constantly, adding/removing columns, changing data types, switching around foreign key constraints, all within safely guarded transactions that I can roll back if I realize that I'm doing something wrong. (And yes: adding/removing/renaming columns is "instant": it doesn't actually do the work of rewriting existing rows on disk.) Frankly, I also use MongoDB, and I'm terrified of screwing much with the schema, because then I either a) have to make certain I have anal documentation about what fields are in use on what subsets of objects, keeping code around to make certain to detect and interpret old kinds of data, or b) use "simplified queries" (really, write a bunch of manual code as if I didn't have a query model at all) in order to find and update these old objects, non-atomically and with no transaction safety. Seriously: the only reason I've so far heard for why having dynamic type verification in my database server is valuable is when you have /so much data/ that it is now fundamentally infeasible to make changes to it with any centralized transaction control--specifically, Google's "it's always the interim somewhere" scenario--not because it is somehow more convenient to do so when you only have in the tens of millions of rows.