MongoDB being non relational disadvantages

Question

I am currently working on a project in the hopes of learning MongoDB.

Reference fields like $ref, $id and $db can reference other documents and collections and dynamically look for changes.

{  
   "_id":ObjectId("53402597d852426020000002"),
   "address": {
   "$ref": "address_home",
   "$id": ObjectId("534009e4d852427820000002"),
   "$db": "school" 
    },
   "contact": "987654321",
   "dob": "01-01-1991",
   "name": "Tom Hanks" 
}

In this scenario this particular document has a reference to a document in the collection ''address_home'' with the object id of 534009e4d852427820000002.

Is these references less effective than PK/FK in popular RDBM's like PostgreSQL or MySQL, and why?

score 2 · Answer 1 · answered Jan 23 '19 at 10:07

2

A DBRef is a glorified id field (that can point to different collections/databases for different records). If all your addresses are in the same known collection, then it's no better than simply having "address_id": ObjectId("534009e4d852427820000002")

It doesn't give you any integrity guarantees, or automatically fetch the referenced document or "dynamically look for changes" (whatever you meant by that). Same thing as a naked id field in relational databases (without FK constraints).

answered Jan 23 '19 at 10:07

Sergio Tulentsev

226,338
43
373
367

https://www.tutorialspoint.com/mongodb/mongodb_database_references.htm - ''The following code dynamically looks in the collection specified by $ref parameter (address_home in our case) for a document with id as specified by $id parameter in DBRef.'' Thanks for the answer! You mention integrity, is that because MySQL cannot have dead PK/FK values? – Jonas Grønbek Jan 23 '19 at 10:19
@JonasGrønbek: without constraints it can. That's why relational dbs have FK constraints. – Sergio Tulentsev Jan 23 '19 at 10:43

Yones · Accepted Answer · 2019-01-23T13:25:43.957

Please consider this comparison mongodb vs mysql. The document based databases are more user friendly than the relational tables of codes and can aggregate in a document schema the logic of many tables saving many relational structures and its processing, multiple access and human strive in programming. The document stores can save documents, code, images(thumbnails and phash) and more creative data freeing the coding team from criptic diagrams to creative solutions. The best friends of document stores of course are JSON, Javascipt's Nodejs and javascript in the frontend.

Welcome to transactional MongoDB4 backed by Views, triggers, dereferences that has the advantage that can be remotely dereferenced giving a hierarchical structure to the database with flexible and scalable topologies and with a Reactive behavior listening to change streams. The databases architecture must tune the granularity and distribution of data over microservices' networks avoiding to build ever growing monoliths. Event Sourcing improves consistency and resiliency.

The FK behavior is a strongly typed mechanism built into the relational database, the document databases can be tuned to perform integrity, consistency and latency depending on requirements with different mechanisms like DBref, Transactional behavior, Change Streams, Functional Triggers, Views consolidation, Reactive behavior, Event Sourcing et al. in a modular composition that coordinates with the modularity of Javascript and Nodejs to fit better in the containerization model of microservices.

This sounds like a marketing pitch for mongodb and not an answer to the question. But it got accepted somehow, so what do I know? — Sergio Tulentsev, Jan 23 '19 at 11:07

MongoDB being non relational disadvantages

2 Answers2