What’s the problem with that? In my previous team, we had a structure with four levels of nesting where we only ever needed to query the first two levels. At first we used Postgres with normalized tables, but it was just slow as hell. Switching to MongoDB actually made our performance issues vanish.
Of course it all depends on what kinds of queries you need to run, but I don’t think that large JSON documents are necessarily a problem.
They’re talking about relations between data. For example, when you delete a user, you may also want to delete their stored data.
To some degree, this is less of a problem with document databases, because they don’t force you to chop your data into small parts like relational databases do (e.g. you can have lists of that user’s stored data as part of the JSON document). But you will likely still need some relations at some point.
Chances are you have a layer in your application code which ensures these relations that way.
Which is fine in my opinion. With relational databases, there’s also often some relations which you cannot model in the database.
But yeah, it requires somewhat more software architecture awareness, to not lump the relation checking logic into general application logic. And you can’t connect a second application to that database, without having to implement the relations another time or at least pulling them out into a shared library.
Every time I’m assigned to a project that uses a document database
“So how are you guys handling all your related data?”
Finds collection of massive JSON documents containing all the related data
“Oh boy.”
What’s the problem with that? In my previous team, we had a structure with four levels of nesting where we only ever needed to query the first two levels. At first we used Postgres with normalized tables, but it was just slow as hell. Switching to MongoDB actually made our performance issues vanish.
Of course it all depends on what kinds of queries you need to run, but I don’t think that large JSON documents are necessarily a problem.
They’re talking about relations between data. For example, when you delete a user, you may also want to delete their stored data.
To some degree, this is less of a problem with document databases, because they don’t force you to chop your data into small parts like relational databases do (e.g. you can have lists of that user’s stored data as part of the JSON document). But you will likely still need some relations at some point.
Chances are you have a layer in your application code which ensures these relations that way.
Which is fine in my opinion. With relational databases, there’s also often some relations which you cannot model in the database.
But yeah, it requires somewhat more software architecture awareness, to not lump the relation checking logic into general application logic. And you can’t connect a second application to that database, without having to implement the relations another time or at least pulling them out into a shared library.
Those are rookie numbers.