关闭。这个问题需要更加突出重点。它目前不接受答案。
**想改进这个问题吗？**通过编辑这篇文章更新这个问题，使它只关注一个问题。

10个月前关门了。
改进这个问题
我正在开发一个应用程序，这是我第一次使用数据库。我选择mongodb是因为最初我认为我的数据结构适合它。经过更多的研究，我对所有可能的数据结构方法都有点迷茫，哪种方法对性能最好，哪种方法对我的数据库类型最好（目前是mongodb，但可以改为postgresql）。以下是我的所有数据结构和迭代：
注意：我理解在下面的示例中，“payrolls”集合有些多余。在这个假设中，它只是用来表示数据层次结构的东西。
原始数据结构

这里的结构与nosql所擅长的是一致的，它可以在单个文档中快速获取所有内容。但是，我打算让我的employee对象保存大量数据，并且我不想因为用户继续向这些雇员添加雇员和数据而侵犯文档大小限制，因此我将他们拆分为一个单独的集合，并使用引用（对象）ID将他们绑定在一起：
第二数据结构

不久之后，我就希望能够独立地操纵客户、地点、部门和员工，但仍然保持他们之间的关系，我的数据结构实现了这个迭代：
第三种和当前的数据结构

正是在这一点上，我开始意识到我已经远离了nosql哲学。现在，我不再对数据库中的一个集合执行一个查询（第1次迭代），也不再对后续填充执行一个查询（第2次迭代），而是在获取数据时并行执行4个查询，尽管所有数据都相互关联。
我的问题
我的第一个数据结构是否适合继续使用mongodb？如果是这样，在employees字段变大时，如何补偿文档大小限制？
我的第二个数据结构是否更适合继续使用mongodb？如果是这样的话，我如何独立地操纵这些字段？我是否为每个字段创建文档模式/模型并按模型查询它们？
我的第三种数据结构是否仍然适用于mongodb，或者我是否应该考虑使用这种分散结构的关系数据库？这种结构是否允许我比其他人更自由或更容易地访问我的数据？