我不是在讨论每个用户多数据库连接的利弊。
你能想到的是一个主数据库，每个人首先连接到它。在这里，您为数据库服务器定义了一个附加表（注意：它们必须可以从连接到它的webfrontend访问！）以及另一个用于user2database关系的表。
另一方面，“应该放在一个安全的地方”意味着更多的是，你没有一个文件与凭证躺在一个空间，可以从互联网上访问。事实上，在代码文件的某个地方，但在webroot之外，这是一种现状。在代码中包含它有一个好处，即即使可以通过web访问它，调用脚本的人也只能看到它的输出，而不能看到源代码。相反，文本文件将按“原样”提供。。。

在我管理的一个应用程序中，每个数据库的凭据都保存在数据库中！因此，该应用程序必须有一种“主”凭证，才能首先连接到一个中央数据库，这样它就可以找出它应该为相应的用户使用什么。该应用程序的主凭据保存在java属性文件中。这是一个java应用程序。
任何语言都可以做类似的事情。例如，php有.ini文件，您可以将其存储在php应用程序旁边，但不在html doc根目录下。用parse\u ini\u file（）加载它们。
对于一个php应用程序，每次请求两次连接到数据库似乎需要做很多工作（java通过维护存在数小时或数天的连接池来缓解这种情况）。如果是这样，您可以将凭据缓存在一个键/值存储中，比如memcached。
所以伪代码/逻辑是：
应用程序初始化以处理请求
从会话或者url或者其他什么来确定用户
检查memcached以查看mysql凭证和数据库是否在缓存中
如果在缓存中找不到：
答。打开ini文件并对其进行分析以获取主凭据。ini文件的位置可以是硬编码的，也可以是环境中的。
b。连接到用户凭据数据库并读取相应应用程序用户的凭据和数据库
c。将凭据和数据库存储在缓存中，以便下一个请求可以快速找到它们
不管怎样，现在应用程序已经准备好连接到正确的用户数据库