3 ms·
Document databases aren't an inherently bad idea. They have their uses. I'm using mongodb because it fits my use case: the app is very front-end oriented, and t
by tgv 3y ago
Document databases aren't an inherently bad idea. They have their uses. I'm using mongodb because it fits my use case: the app is very front-end oriented, and the data the user needs on a specific page fits neatly in one document. There are (quite a lot) related documents, but they are only needed in specific parts of the app, and that's when those are retrieved. Pretty simple.
I could argue that in-server SQLite is a bad idea: if you ever need to share the database or distribute tasks, you're fucked. But for some use cases it just works.
"The world" hasn't realized shit. It jumps from fad to fad, fueled by hyped promises and lack of experience.
- eddd-ddde 3y agoWhat about a Postgres database where you store your documents in a key value table of json objects? What mongodb benefits would you be missing?
- tgv 3y agoWhat benefit does switching to postgresql bring? When mongodb stops being maintained, I'll consider postgres, but until then, I now only see downsides.
- eddd-ddde 3y agoLot's of useful features? You can join data when needed, proper transactions, schemas where you need schemas. For example you start with a basic (key, json) table. Once you begin to stabilise your schema, add columns generated from your json objects, now you can get proper joins, indexes, validations, on said columns.