I’m trying to understand what types of models that I have traditionally persisted relationally would translate well to some kind of NoSQL database. Suppose I have a model with the following relationships:
Product 1-----0..N Order
Customer 1-----0..N Order
And suppose I need to frequently query things like All Orders, All Products, All Customers, All Orders for Given Customer, All Orders for Given Product. My feeling is that this kind of model would not denormalize cleanly – If I had Product and Customer documents with embedded Orders, both documents would have duplicate orders.
So I think I’d need separate documents for all three entities. Does a characteristic like this typically indicate that a document database is not well suited for a given model? Generally speaking, would a document database perform as well as a relational database in this kind of situation?
I know very little about graph databases, but I understand that a graph database handles relationships more performantly than a document database – would a graph database be suited for this kind of model?
5
In my opinion a document database would not be right for this. I have limited experience, though.
My experience:
15 years of SQL Server, 2 years of Postgres, only 2 projects with MongoDB.
After my years with relational databases I might be biased. But I have really tried to embrace the document concept. It is really great when you have documents, i.e. items that you want to update atomically.
You are describing relations. Relations belong in a relational database. There might be some more evolved document databases which are better for relational data. But they really are built for other uses.
After building some spikes with MongoDB, I built a Node project for relaying data between several external APIs and our own API. The server has been running for a couple of years and handles a couple of hundred thousand imports a year.
MongoDB seemed to be a great fit for this. But as soon as I added user and access control I started to long after a relational db again.
Document databases encourage you to throw everything at it. I challenge I encountered was version handling between different shaped json objects in the same collection (table). I ended up using JSON schema to validate everything going into the collections. This took away some of the freedom I gained by using MongoDB in the first place.
If I’d build that project again I’d do it with Postgres.
Two years ago I started a new project (Node server, React Native app). I started out with MongoDB, but the exact same thing bit me again. As soon as you start to handle users, ACL and critical relations you’ll grow out of MongoDB. I switched to Postgres and the DB now consists of approx 100 normalized tables.
Postgres has a JSON field type which more than well makes up for what I missed from MongoDB.
Summary:
Querying for data in MongoDB is no problem. You’ll find everything you need in a snap. Indexing capabilities are great as well.
Keeping your relational data secure will be a challenge in MongoDB. ACID is the way to go imho.
If I’d grow out of the JSON field type in Postgres I could see myself using MongoDB for some storage, but the main db would definitely be relational.