4 ms·
It’s useful for prototyping. When you don’t know which schema you’ll end up using having an *SQL database is tedious because you have to do migrations every tim
by hk__2 10y ago
It’s useful for prototyping. When you don’t know which schema you’ll end up using having an *SQL database is tedious because you have to do migrations every time you change the schema. Once you’re done prototyping you can switch to a better alternative.
- kinkdr 10y agoExactly. Use the right tool for the right job. Start prototyping and development with MongoDB and then migrate to Postgres, or Cassandra or whatever suits your user-case better.
- kinkdr 10y agoOops.. did I say something wrong?
- balfirevic 10y agoHow does that work? If you need to preserve data between the application versions then you still get all the headaches with MongoDb (either migrating the data or supporting multiple schema versions when you read the data, oh the fun!). If you don't need to preserve data between the versions then you don't need to write migrations scripts in SQL, just scrape everything and pretend it's the first version of application.
- collyw 10y agoI have never managed to build a prototype that didn't end up being used in a production setting. I am trying to remember if I ever built a prototype that got rewritten. Probably not.
- hk__2 10y agoIt probably won’t get rewritten but the DB-specific code is in one module so it’s easy(-ish) to swap the underlying DB.
- PeterisP 10y agoIn that case you can start with postgres and stuff your documents in a single json column, accessing it just as you would have in mongo while you're prototyping and don't care about speed and indexing, and when you're done, you can just change that table to a more proper structure without changing databases.
- virmundi 10y agoI guess this is a question of how usefuly, deployable the prototype shoukd be. Why not just have an in memory object cache, literally a hashmap, for your dal? If you're composing app level code, you don't need to know what the backend does to your data. You could even create a simple method to populate the data at app boot in your in the dev profile. When you figure out the storage requirements and finalized model, build your db. This would save you time on picking the db, schema changes or even migration changes in Mongo. You don't have to worry about bad documents from an earlier app revision.
- hk__2 10y ago> You could even create a simple method to populate the data at app boot in your in the dev profile I have ~40M documents, and it’s still a subset of what I’ll manage in production. It takes a few hours to load them in the database.
- matwood 10y agoUse SQLite and let the tool drop and recreate all the tables during prototyping. No migrations required.
- hk__2 10y agoSQLite can’t handle a large number of documents; I have ~40M of them.