re: Convince me to use SQL VIEW POST

re: NoSql databases have their place, but it's not a replacement for relational databases. A document db such as MongoDb can't replace and shouldn't be...

You can still easily do relational data in NoSQL. The difference is for relational data in NoSQL you need to know ahead of time the specific access pattern in order to model the relationship. Whereas SQL you normalize all your data and you can access it anyway you want and add new access patterns with a breeze. However, at scale NoSQL will outperform SQL any day because you model your data for those specific access patterns making it super efficient compared to doing all of these joins across tables.

In short, have known and consistent access patterns? Use NoSQL. Otherwise use SQL.


have known and consistent access patterns

It would be impossible NOT to be known and consistent, actually.

I believe denormalized database is fast, but how much can I trust aggregation framework? Especially on the $lookup part.

The real problem that cannot be denormalized here is -- MongoDB cannot have nested objects that are passed by reference. (I saw closed issue on this somewhere.)

It's not impossible to have known and consistent access patterns. There are many apps that can have known patterns, even with NoSQL it's not impossible to add new access patterns just a little bit harder.

I also do not use $lookup I do not use MongoDB at all. I use DynamoDB mainly.


OP wrote "I care most about data integrity, monitoring and maintainability, rather than performance;" - IMHO, a well designed relational database makes it easy to enforce data integrity, and with some carefully planed indexes, should have no performance problems.

I'm no expert when it comes to NoSql but I have been working with MongoDb for a couple of years (thought admittedly, not a very intensive work) and I've yet to encounter anything it can do faster than SQL Server - but that might be because of a lack of MongoDb knowledge on my part.

My point is, for a hard structured, relational data, I see no reason not to work with a relational database. Query speed optimizations can be made when needed, even at the cost of denormalized (flatten) data - yet still keeping the data integrity.

Sure maybe what OP wants in this specific case is SQL I wont argue that side. I also said at scale NoSQL is faster. SQL is faster when you are working with small datasets. However, once you have an application that is at scale, like say the company I'm working with right now that has 100 million records SQL is no longer performant. However, after being switch to NoSQL DynamoDB every single access pattern they have can be queried in under 40ms every single time.

Code of Conduct Report abuse