Mysql 建立具有子组的组织

我正在努力解决一个数据库设计问题，这是一个冗长的问题：

我的网站将有无限数量的组织用户，他们可以加入，这些组织下的子组，最后为这些子组的具体配置文件。同一组织内的子组将能够相互借用和更改配置文件。用户将生成组织、子组和配置文件

我可以把它画出来，让流程在纸上变得合理。当涉及到实际将其放入任一SQL时，我就不知所措了。大多数的帮助指南都假定为静态组，因此简单的主键和外键设置可以引用正确的信息。据我所知，我的系统有太多的动态信息，这些信息中的大多数无法直接工作

大多数作者都说远离动态生成的表，但这是我的直觉告诉我的。我的另一个想法是为所有组织、团体和个人资料创建3个大型表格

那么有没有更好的方法来解决这个问题呢？或者，有没有什么好的文档可以让我阅读，帮助我将图纸翻译成实际的代码

如果这有助于解释问题的话，我对SQL和MongoDB都有一些经验。

我不知道MongoDB（NoSQL），但从SQL的角度来看，我的观点如下

就您的模式而言，大多数情况下，当您的“本能”表明：-对于您正在处理的某些问题，只有“动态表”解决方案是您的最佳选择

请记住，非常有可能通过具有不同关系的多个静态表来解决问题。（我所说的静态是指您作为开发人员自己创建的那些。）

我还想提到的是，我自己在最初的日子里也一直想用类似的方法来解决问题，但后来我开始理解数据库的原理和工作原理

回到您的问题：- 如果您的组织雇佣人员由三种主要类型的对象/级别组成，即：。组织、组和概要文件然后我建议您使用3个具有正确关系的表，与在运行时创建表相比，任何SQL引擎在处理这些表时都非常高效

---

现在，如果层级结构是动态的，比如说，一个组织可以包含许多组，这些组又应该包含配置文件，这些配置文件应该/可以包含其他组织，等等。。。。然后，您可能希望使用SQL（递归）查看递归结构。（只需在谷歌上搜索一下，有很多关于这方面的文章。）

为什么这同时标记了MySQL和MongoDB——这两个截然不同的系统？你关于三张“大”桌子的想法似乎是正确的方法。我不确定我是否遗漏了任何一张桌子，这两张桌子都可以让事情变得更简单。目前我正处于初始设计阶段，所以我有空间去做任何一种方式。它不需要是递归的，最多支持三层。我试图对此进行建模，我认为我需要至少3个额外的静态表，用于组织和子组的成员身份，以及一个用于组织的子组。最终配置文件将包含它所属的组织和子组以及帐户上的主要用户的外键。但是，如果有多个用户可以在一个帐户上拥有辅助状态，我是否需要创建另一个表？或者我缺少的任何其他帮助？“如果有多个用户可以在一个帐户上拥有辅助状态”，因为

帐户可以有多个用户（一个主用户和另一个辅助用户），您可以始终在名为
userstatus
的新表上创建一对多关系，其中的列将是
id，userid，accountid，type
其中类型可以是布尔值，0表示次要的，1表示主要的。谢谢，这有助于我建模我的逻辑，这样我就可以用我们最终使用的任何一种数据库结构来构建它！很高兴我的解决方案在某种程度上帮助了您：）