我目前正在研究一个项目,希望学习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''
为534009e4d852427820000002
的集合{{1}}中文档的引用。
这些引用在流行的RDBM(如PostgreSQL或MySQL)中是否不如PK / FK有效,为什么?
答案 0 :(得分:2)
DBRef是美化的id字段(可以指向不同记录的不同集合/数据库)。如果您所有的地址都在同一个已知集合中,那无非就是简单地拥有"address_id": ObjectId("534009e4d852427820000002")
它不会为您提供任何完整性保证,也不会自动获取引用的文档或“动态地寻找更改”(无论您要做什么)。与关系数据库中的裸ID字段相同(不受FK约束)。
答案 1 :(得分:-1)
请考虑进行此比较mongodb vs mysql。基于文档的数据库比代码的关系表对用户更友好,并且可以在文档架构中聚合许多表的逻辑,从而节省了许多关系结构及其处理,多次访问和人工编程工作。文档存储可以保存文档,代码,图像(缩略图和phash)以及更多的创意数据,从而使编码团队摆脱了从简图到创意解决方案的麻烦。 当然,文档存储最好的朋友是JSON,前端的Javascipt的Nodejs和javascript。
欢迎使用transactional MongoDB4,Views,triggers支持的dereferences,它的优点是可以远程取消引用,从而为数据库提供具有灵活和可扩展拓扑的层次结构并具有反应性行为listening to change streams。数据库体系结构必须调整microservices'网络上数据的粒度和分布,避免构建不断增长的整体。 Event Sourcing改善了一致性和弹性。
FK行为是关系数据库中内置的强类型机制,可以根据要求使用不同的机制(例如DBref,事务行为,变更流,功能触发器,视图合并)来调整文档数据库以执行完整性,一致性和延迟,反应行为,事件来源等。与Javascript和Nodejs的模块化相协调的模块化组合,以更好地适合微服务的容器化模型。