我正在努力解决数据库设计问题，这是一个冗长的问题：
我的网站将拥有无限数量的可加入的组织用户，这些组织下的子组以及最终这些子组的特定配置文件。同一组织内的子组将能够相互借用和更改配置文件。用户将生成组织，子组和配置文件。
我可以画出来，让流动在纸上合理。当涉及到实际将它放到SQL中时我就迷失了。大多数帮助指南都假定为静态组，因此简单的主键和外键设置可以参考正确的信息。根据我的理解，我的大部分工作都有太多的动态信息直接工作。
大多数作家都说远离动态生成的表格，但这就是我的本能带我的地方。我的另一个想法是3个大型表格，适用于所有组织，组和个人档案。
那么还有更好的方法吗？或者是否有任何好的文件我应该阅读以帮助我从绘图转换为实际代码？
我对SQL和MongoDB都有一些经验，如果这有助于解释事情。
答案 0 :(得分：1)
我不知道MongoDB（NoSQL），但从SQL的角度来看，这是我的观点。
就您的架构而言，大多数情况下，当您的“本能”表明： - 只有“动态表”解决方案是您最好的选择，对于您正在处理的某些问题
请记住，具有不同关系的多个静态表很有可能解决 这个问题。 （静态我的意思是你自己创建的开发人员。）
另外我想提一下，在我最初的几天里，我也一直想着以类似的方式解决问题，但后来我开始理解原则以及数据库的确切运作方式。
回到您的问题： - 如果您的组织hirerchy包含三种主要类型的对象/级别，即。组织，组和配置文件然后我建议您使用正确关系的3个表，与在运行时创建表相比，任何SQL引擎在处理时都是安静有效的。
现在，如果层次结构是动态的，例如，一个组织可以包含许多组，而这些组又应包含再次应该/可以包含其他组织的配置文件等等。那么你可能想看看带有SQL的递归结构（递归）。 （只是进行谷歌搜索，有很多关于此的文章。）