3 ms·
> Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes. It's not hard to make it easy to do a thing i
by joepie91_ 11y ago
> Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes.
It's not hard to make it easy to do a thing in the wrong way - and that's exactly what MongoDB does. It doesn't make you set up authentication or table schemas, so it looks 'really easy to set up'.
In reality, though, you're wasting hours to save 10 minutes. Because at a later point, you're going to have your database broken into (if it can even be called that, without authentication), or you end up corrupting your data because two of your applications disagree over what the current object schema is.
To know how easy something really is, you need to compare how hard it is to set something up correctly. And once you do that, MongoDB falls far behind.
- djacobs 11y agoI'm all for using tools that don't make bad things easy, but I think threeseed is saying that for hacks and spikes, the "later point" you're referring to might not matter. (I agree that those are the only jobs I'd use Mongo for, too.) Of course, if you're at a company where those spikes find a way of turning into production code, then it's a different story.
- joepie91_ 11y agoRealistically, though, almost always at least some portion of your hacks makes it into production. And if you're saving 10 minutes for 5 hours lost, then even at a going-into-production-rate of 10%, it's still not worth it. Hacks that remain hacks in 100% of the cases, are rare :)
- derefr 11y agoI've always thought it would be a great idea to create an explicit "prototyping database" that has limitations that actually prevent you from putting it in production, no matter how small your use-case. Things like "erases random rows after 24 hours" or "default row limit of 100; can increment this by 100 once per day by solving a CAPTCHA."
- djacobs 11y agoI think my experience is different from yours (I don't let spikes make it past my own branch), but as far as production goes, we're on the same page!
- threeseed 11y agoWhat exactly are you talking about ? 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. And yes MongoDB is schemaless. That doesn't mean your data is going to automatically corrupt itself. You can just define your schema in some shared library. I can just as easily corrupt PostgreSQL if I change data types without updating the ORM.
- joepie91_ 11y ago> 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 https://news.ycombinator.com/item?id=9913563 > And yes MongoDB is schemaless. That doesn't mean your data is going to automatically corrupt itself. You can just define your schema in some shared library. This doesn't work if there is no shared library, for example if you have two separate components in different languages both using the database. And at that point you're (poorly) reinventing a schemaful database anyway. > I can just as easily corrupt PostgreSQL if I change data types without updating the ORM. A good ORM will abide by your database schema - and no, you can't "corrupt PostgreSQl" by "not updating your ORM". It will, at most, error out because you're trying to work with non-existent columns. In a schemaless database, there's no such thing as "non-existent columns", thus you can quietly corrupt data without realizing it.