3 ms·

Hi Michael, from a development standpoint only, I like the fact that I don't have to write database migrations (as defined in Rails). It means I can iterate mo

Hi Michael, from a development standpoint only, I like the fact that I don't have to write database migrations (as defined in Rails). It means I can iterate more quickly during the development. As well for data aggregation kind of jobs (such as http://www.toutpourmonipad.com/ http://www.toutpourmonipad.com/ where I munge different-formatted data streams), it's really convenient to be able to mix datas that are partly equal, partly different, when it's relevant to you. Edit: forgot to mention that MongoDB comes with a built-in geographical index (MySQL doesn't have it, I'm not sure for PostGres - I believe it's via some extension). Edit2: forgot to mention I really appreciate the upsert abilities for what I do (http://www.mongodb.org/display/DOCS/Updating#Updating-UpsertswithModifiers http://www.mongodb.org/display/DOCS/Updating#Updating-Upsert...) Edit3: anyone with some curiosity for MongoDB will appreciate this book: http://www.amazon.com/MongoDB-Definitive-Guide-Kristina-Chodorow/dp/1449381561 http://www.amazon.com/MongoDB-Definitive-Guide-Kristina-Chod... - well-written and concise

saurik 16y ago
This is because you are simply never updating your schema: if you actually want to rename a field, change a datatype, or reorganize your content, you are still going to need to run a migration, and now it won't even be possible to transanction lock the upgrade (better database servers, like PostgreSQL, can do multiple whole-daabase schema modifications within a transaction while still allowing non-conflicting access). In essence, your underlying schema is now "id->blob". ;(
- thibaut_barrere 16y ago
  The OP question was "during development". I obviously change the schema in production too: sometimes keeping null-values will work, sometimes a migration will be needed. My point is that I only do the "production" migration when needed and once per release that requires it, while I can tweak the schema at ease while developing. If you have a large-enough volume of data, you will meet the situation where just adding a single column takes ages, too.
  - jamwt 16y ago
    Do a lazy migration--aka, every document gets tagged with current version. The restoration/model routines have a transparent upgrade chain (1->2, 2->3) that move any loaded document up the chain until they reach the current version; then, the app code acts as though all documents are magically updated. If you're worried about performance, have the upgrade chain write out the latest version so it's only upgraded once. Works like a charm. No migration headaches.
  - saurik 16y ago
    Adding/deleting/renaming a column is instantaneous as it doesn't involve updating any of the rows on disk: I add columns to tables that have a hundred million rows all the time. (PostgreSQL)

saurik 16y ago

This is because you are simply never updating your schema: if you actually want to rename a field, change a datatype, or reorganize your content, you are still going to need to run a migration, and now it won't even be possible to transanction lock the upgrade (better database servers, like PostgreSQL, can do multiple whole-daabase schema modifications within a transaction while still allowing non-conflicting access). In essence, your underlying schema is now "id->blob". ;(

thibaut_barrere 16y ago
The OP question was "during development". I obviously change the schema in production too: sometimes keeping null-values will work, sometimes a migration will be needed. My point is that I only do the "production" migration when needed and once per release that requires it, while I can tweak the schema at ease while developing. If you have a large-enough volume of data, you will meet the situation where just adding a single column takes ages, too.
- jamwt 16y ago
  Do a lazy migration--aka, every document gets tagged with current version. The restoration/model routines have a transparent upgrade chain (1->2, 2->3) that move any loaded document up the chain until they reach the current version; then, the app code acts as though all documents are magically updated. If you're worried about performance, have the upgrade chain write out the latest version so it's only upgraded once. Works like a charm. No migration headaches.
- saurik 16y ago
  Adding/deleting/renaming a column is instantaneous as it doesn't involve updating any of the rows on disk: I add columns to tables that have a hundred million rows all the time. (PostgreSQL)