MongoDB 是非相关的劣势

Question

我目前正在做一个项目，希望学习 MongoDB。

$ref、$id 和 $db 等引用字段可以引用其他文档和集合并动态查找更改。

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

在这种情况下，此特定文档引用了集合 ''address_home'' 中对象 ID 为 534009e4d852427820000002 的文档。

在像 PostgreSQL 或 MySQL 等流行的 RDBM 中，这些引用是否不如 PK/FK 有效，为什么？

Answer 1

DBRef 是一个美化的 id 字段（对于不同的记录可以指向不同的 collections/databases）。如果您所有的地址都在同一个已知集合中，那么它并不比简单地拥有 "address_id": ObjectId("534009e4d852427820000002")

更好

它不会为您提供任何完整性保证，也不会自动获取引用的文档或 "dynamically look for changes"（无论您指的是什么）。与关系数据库中的裸 id 字段相同（没有 FK 约束）。

Answer 2

请考虑这个比较mongodb vs mysql。基于文档的数据库比代码的关系表对用户更友好，并且可以在文档模式中聚合许多表的逻辑，从而保存许多关系结构及其处理、多路访问和编程中的人工努力。文档存储可以保存文档、代码、图像（缩略图和 phash）和更多创意数据，使编码团队从繁琐的图表中解放出来，转向创意解决方案。文档存储最好的朋友当然是JSON，Javascipt的Nodejs和前端的javascript。

欢迎使用 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 提高一致性和弹性。

FK 行为是一种内置于关系数据库中的强类型机制，可以根据不同机制（如 DBref、事务行为、变更流、功能触发器、视图整合、反应行为、事件源等。在与 Javascript 和 Nodejs 的模块化协调的模块化组合中，以更好地适应微服务的容器化模型。

MongoDB 是非相关的劣势

MongoDB being non relational disadvantages

database

relational

reference

mongodb