4

Here is where I am at right now: I know that relational data, like that found in relational databases like MySQL or Postgres, is relational because there are relations between the tables. That is the reason why RDBMS have rigid schemas. On the other hand, NoSQL databases offer a looser schema but lose those relations. But MongoDB, for instance, offers official support (or at least blog posts) for associations between data (One-To-One, One-To-Many, etc).

Now I am really unsure if the data I am going to have in a project is relational and therefore if MongoDB would be a bad choice. People keep mentioning you should not use NoSQL databases unless you have a specific reason to use them over traditional RDBMS. But I really like MongoDB, especially for GraphQL. Working in JavaScript, I love working with Mongoose. My data structure, on the other hand, seems kind of relational (users have machines, machines are inside rooms, that are also owned by users).

I am really confused. Everyone keeps going on and on about the MERN/MEVN/MEAN stack and how awesome MongoDB is with Node which I agree and I love it, but sometimes people tend to jump onto the hype train too much. Can you give me your thoughts on this one?

IchBinGrumpig
  • 67

1 Answers1

4

There is no difference between relational and non-relational data. The data is the data. It is a basic aspect of the domain addressed by the application. It does not, or should not, change depending on the technology used to process it.

What differs is the affordances of the various DBMSs and their data models. All a key-value system can really do is persist a blob and return it when asked. It can't filter, join or aggregate because it has no understanding of what is in those blobs. Document databases can do those things but (generally) forgo referential integrity and ACID. Graph databases make it easier to explore the connectedness of your data but might not be the best for, say, summing billions of identical transactions.

Each model of data storage will be able to persist your data. The question then becomes one of balancing project risks. What do you want the DBMS to do for you, what do you want to handle in the application, and what can you afford to ignore completely. How familiar are you, and so how productive can you be, with each of these technologies. What licence/ hardware/ support/ training/ recruitment costs is the organisation prepared to bear.

Michael Green
  • 923