3

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?

Improve this question
10
  • 11
    Just want to clarify one thing about "relational": The word does not refer to the relations between the tables. A 'relation' is a table, and the word describes how the 'tuples' (rows) and the 'attributes' (columns) relate to each other. There's a mathematical formalism there that lends itself to a certain kind of storage and processing capabilities. Non-relational data structures tend to have other capabilities. But, it's not the tables and relationships between them that define 'relational' and 'non-relational'
    – Eric King
    Apr 3, 2020 at 15:28
  • 2
    @EricKing Might as well mention that this formalism is called tuple-relational calculus.
    – Polygnome
    Apr 3, 2020 at 20:02
  • @Polygnome, as an aside, I don't know whether it's just me, but I've never found that calculus useful, from the perspective of a user of relational databases (rather than someone implementing a query engine). Even though I'm aware the engine can rearrange queries, I always write them with a logical order of execution in mind. I always think in the real world, teaching relational theory puts people on completely the wrong footing, because it describes how a given query can be manipulated whilst maintaining correctness, it is not at all consistent with how the base case is conceived.
    – Steve
    Apr 4, 2020 at 13:28
  • @Steve I have found that knowing the basis of the technology you are using leads to a far better understanding of the technology - its capabilities, but also its limits. And when to use and and when not.
    – Polygnome
    Apr 4, 2020 at 13:29
  • @Polygnome, as a rule I agree, but in this case it falls down for a number of reasons. Some thoughts. Firstly, most database engines incorporate functionality that is either not consistent with or not covered by relational theory - most of which have arisen precisely because a pure relational approach was awkward and wildly complex, or even impossible. Secondly, a query that is rearranged to be relationally equivalent, may not be equivalent in terms of things like deadlock risk, and reasoning with relational theory will tell you nothing about this kind of equivalence.
    – Steve
    Apr 4, 2020 at 13:48

1 Answer 1

Reset to default
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.