在我深入潜入MongoDB几天之前,我想我会问一个非常基本的问题,我是否应该深入研究它.我基本上没有使用nosql的经验.
我确实读过一些文档数据库的一些好处,我认为对于这个新的应用程序,它们会非常棒.对于许多类型的对象(许多m-to-m关系)和子类来说,做收藏夹,评论等总是很麻烦 - 这是一种很难处理的问题.
我还有一个结构,在SQL中定义会很麻烦,因为它非常嵌套并且比15个不同的表更好地转换为文档.
但我对一些事情感到困惑.
是否可以保持数据库的标准化？我真的不想更新多条记录.这仍然是人们如何处理MongoDB中数据库的设计？
当用户收藏某本书并且此选择仍存储在用户文档中时,会发生什么情况,但该书籍会被删除？没有外键,关系如何分离？我自己负责删除所有链接吗？
如果用户喜欢不再存在的书并且我查询它(某种类型的连接)会发生什么？我必须在这里做任何容错吗？
Tomasz Stanc.. 62
MongoDB不支持服务器端外键关系,也不鼓励规范化.如果可能,您应该将子对象嵌入父对象中,这将提高性能并使外键完全不必要.也就是说它并不总是可行的,所以有一个名为DBRef的特殊构造允许引用不同集合中的对象.这可能不那么快,因为DB必须进行额外的查询才能读取对象,但允许进行外键引用.
您仍然需要手动处理您的参考.只有在查找DBRef时,您才会看到它是否存在,如果引用的目标不再存在,DB将不会遍历所有文档以查找引用并删除它们.但我认为删除书后删除所有引用将需要每个集合一个查询,不再需要,所以不是那么困难.
如果您的架构更复杂,那么您可能应该选择关系数据库而不是nosql.
还有一本关于设计MongoDB数据库的书:MongoDB的文档设计
更新上面的书已不再可用,但由于MongoDB的普及,还有很多其他的.我不会将它们全部链接起来,因为这样的链接可能会改变,亚马逊上的简单搜索会显示多个页面,因此查找一些页面应该不会有问题.
有关详细信息和示例,请参阅MongoDB手册页中的"手动参考"和DBRefs
MongoDB不支持服务器端外键关系,也不鼓励规范化.如果可能,您应该将子对象嵌入父对象中,这将提高性能并使外键完全不必要.也就是说它并不总是可行的,所以有一个名为DBRef的特殊构造允许引用不同集合中的对象.这可能不那么快,因为DB必须进行额外的查询才能读取对象,但允许进行外键引用.
您仍然需要手动处理您的参考.只有在查找DBRef时,您才会看到它是否存在,如果引用的目标不再存在,DB将不会遍历所有文档以查找引用并删除它们.但我认为删除书后删除所有引用将需要每个集合一个查询,不再需要,所以不是那么困难.
如果您的架构更复杂,那么您可能应该选择关系数据库而不是nosql.
还有一本关于设计MongoDB数据库的书:MongoDB的文档设计
更新上面的书已不再可用,但由于MongoDB的普及,还有很多其他的.我不会将它们全部链接起来,因为这样的链接可能会改变,亚马逊上的简单搜索会显示多个页面,因此查找一些页面应该不会有问题.
有关详细信息和示例,请参阅MongoDB手册页中的"手动参考"和DBRefs
以上,@ TomaaszStanczak说
MongoDB不支持服务器端外键关系,也不鼓励规范化.如果可能,您应该将子对象嵌入父对象中,这将提高性能并使外键完全不必要.那说它并不总是可能......
Mongo不鼓励标准化.为了清楚起见,我们讨论的是两个数据实体可以拥有的两种根本不同的关系类型.在一个中,一个子实体仅由父对象拥有.在这种关系中,Mongo的方式是嵌入.
在另一类关系中,两个实体独立存在 - 具有独立的生命周期和关系.Mongo希望这种关系不存在,并且对于如何处理这种关系感到沮丧.嵌入不是解决方案.不鼓励或鼓励标准化.Mongo只给你两种机制来处理它; 手动引用(类似于绑定两个表的外键约束的键)和 DBRef(一种不同的,稍微更结构化的方式).在这个用例中SQL数据库获胜.
京公网安备 11010802040832号 | 京ICP备19059560号-6 