101–110 of 122 posts
Not even a hackathon?
MongoDB has THE WORST vendor lock-in imaginable, so only use it if you know that you could throw everything away. Source: my last employer used MongoDB, and switching to an RDBMS would have forced us to rewrite ~80% of the codebase.
Now with PostgreSQL 9.4 there isn't really any reason to use MongoDB (JSONB is better suited than BSON). For any other use CouchDB.
sadly, meteor uses mongo and only mongo. And we are using meteor (which is based on node) Two levels: node and mongo == two levels of sadness. (let the flames commence)
Now with PostgreSQL 9.4 there isn't really any reason to use MongoDB (JSONB is better suited than BSON). For any other use CouchDB.
pg 9.5 with partial updates, for now pg jsonb support is inferior if you want to perform partial modifications.
Earlier quoted context omitted.
> Why would I care about having my database broken into or even my data being corrupted for hacks/spikes. The very definition of these is that they are throwaway designed to test an idea before rebuilding in something more suitable. No. There's no rule that says a prototype must be thrown away - often, it can be built upon further. See also https://news.ycombinator.com/item?id=9913563 > And yes MongoDB is schemaless.…
Actually following proper Agile process you do throw your prototype away. And yes you can corrupt PostgreSQL. Change the data types without updating your ORM.
I once started consulting on a Rails app project which used MongoDB. But I was never able to get productive: I had my development environment all set up, but then the code wouldn't work with the development database. I pinged the other dev:
"Oh, I made changes to the data model. I'll zip up and email you a new copy of the dev database."
This continued for a couple of iterations and I had to quit the project because I could never continuously get work done.
Earlier quoted context omitted.
pg 9.5 with partial updates, for now pg jsonb support is inferior if you want to perform partial modifications.
There are no partial updates in 9.5. There likely never will be in Postgres, due to MVCC.
On the WAL level there's partial UPDATEs btw.
Earlier quoted context omitted.
> Why would I care about having my database broken into or even my data being corrupted for hacks/spikes. The very definition of these is that they are throwaway designed to test an idea before rebuilding in something more suitable. No. There's no rule that says a prototype must be thrown away - often, it can be built upon further. See also https://news.ycombinator.com/item?id=9913563 > And yes MongoDB is schemaless.…
Actually following proper Agile process you do throw your prototype away. And yes you can corrupt PostgreSQL. Change the data types without updating your ORM.
MongoDB is awful for development. I once started consulting on a Rails app project which used MongoDB. But I was never able to get productive: I had my development environment all set up, but then the code wouldn't work with the development database. I pinged the other dev: "Oh, I made changes to the data model. I'll zip up and email you a new copy of the dev database." This continued for a couple of iterations and I…
But your painful problems seems more like a problem with communication/documentation practices. DB changes will occur with SQL databases. It is about equally important to communicate them to other users of the DB. (But OK, it is easier to find the changes with an SQL DB.)
(Yeah, I'm hellbanned.)
MongoDB is awful for development. I once started consulting on a Rails app project which used MongoDB. But I was never able to get productive: I had my development environment all set up, but then the code wouldn't work with the development database. I pinged the other dev: "Oh, I made changes to the data model. I'll zip up and email you a new copy of the dev database." This continued for a couple of iterations and I…
Earlier quoted context omitted.
I don't understand why a schemaless database is so great for prototyping. Most of the pain from schema changes is when you have a lot of code or a lot of users depending on an existing schema, so it's hard to change (or at least, hard to change while maintaining uptime). Running ALTER TABLE on a small dataset with almost no users is trivial.
Schemaless is just one aspect the other one is clustering/replication. Not sure about MongoDB but CouchDB has master-less peer to peer replication built in. That is hard to bolt-on later on top of Postgres and other databases. Just saying that is another factor in play, not just schema vs no-schema.