从SQL到Mongo的数据库设计方法

我想了解如何解决Mongo上的某些问题，我使用SQL已经有一段时间了，我知道DB设计的基础知识，其中许多在Mongo中是无用的，因为它是完全不同的

这里有一个例子。我有用户凭据（用户名、密码）、用户信息（姓名、姓氏等）和用户facebook信息（好友列表、好友、ecc）。在MySQL中，一种很好的组织方式是在3个表中，一个用于凭证，一个用于一般用户信息，一个用于fb用户信息，所有3个表都与用户ID相关。这样，如果我需要登录用户，我只需要查询凭证表，该表具有非常轻的行（3列；ID、用户名、密码）

那么，如何将这个论点转化为非关系领域呢？我是否通过将常规信息和facebook信息添加为数组来扩展我的用户对象

user =>array(
              'username' => 'user1', 
              'password' => 'pass1',
              'gInfo'    => array('name' => '','lastname' => ''),
              'fbInfo'   => array('likes' => '','friends' => '')
)

---

或者像在SQL中一样，如果我创建了两个与用户的Mongo _ID相关的新对象，效果会更好。

下面是您的真实案例

“我所谓的‘关系’是否超出了每个用户的‘记录’的合理数量，将这些信息保存在单独的‘关系’存储中是否有意义？”

因此，如果您对此的回答是否，那么您是使用MongoDB“”表单的好人选。部分答案可能来自“我总是这样做，因为他们告诉我这样做”

MongoDB存在的一半原因是提供了一种替代“第二范式”、“第三范式”语义建模的方法，在这种情况下，对使用模式和存储需求有意义。一般来说，文档嵌入概念的存在是为了避免获取的需要来自另一个集合的“相关”结果，因为结果已嵌入响应文档中

有不同的Id更好吗？你是说在不同的集合中。MongoDB在哪里 不加入联接< /强>。那么情况可能不会，但如果需要，那么考虑后果。

正如睿智的绝地所说，“忘却你所学到的”，并将不同的思维方式应用到你的模式设计中，MongoDB将非常适合你

---

祝你好运，学徒。

你设计MySQL的方式会不会打破2/3NF？是的，你通常只会扩展你的用户对象来存储关于单个基因的所有数据，除非有性能原因我没有注意到你说过：这样，如果我需要登录用户，我只需要查询具有非常轻的行的凭证表“我非常怀疑拆分表（适用于非常高的使用率）是否能获得任何性能”事实上，由于需要查询更多的表并写出更多的IO，您可能会得到更低的性能。是的，设计mongo db与您通常使用关系型db的做法确实不同。Lookie您的问题很常见，我是否应该嵌入或引用，看看我对这个问题的回答，可能对您有所帮助@MaksymStrukov I think这是在我的回答中涵盖的comments@Neil你这是什么意思？