Architecture 选择数据库连接 假想系统

考虑一个系统，它公开一个web UI，但使用同一数据库模式的多个实例。假设每个用户都属于某个较大的实体，称之为“组织”，并且每个组织都有自己的数据库实例。当用户登录时，系统应确定使用哪个数据库实例

这种系统表面上要求将连接字符串存储在一个集中的数据库中。乍一看，系统仍然需要一个中央数据库，这似乎违背了每个组织拥有自己数据库的目的。其次，我已经读到，首先在数据库中存储连接字符串是不可取的。最后一个观察结果是，将用户登录信息映射到连接字符串是系统确定使用哪个数据库实例的唯一方法，这对我来说似乎很幼稚，但我想不出替代方法

我的问题如下:

我的初步评估是否正确，即这个假设的系统实际上需要一个集中的数据库来将用户登录信息映射到对应于该用户所属组织的连接字符串

如果需要一个集中式数据库，那么这是否一定会违背每个组织拥有自己的数据库实例的目的

在数据库中存储连接字符串真的是个坏主意吗？为什么？在数据库中存储连接字符串时应考虑哪些问题和顾虑

将登录信息映射到连接字符串真的是网站知道使用哪个数据库实例的唯一方法吗？还有什么其他的技术

不，根据用户标识符的不同，可能存在替代方案。例如，如果您使用电子邮件地址来标识用户，并且可以确保每个组织只使用一组已知（且唯一）的域，则您可以仅在域部分上选择正确的数据库。您可以将域数据库信息存储在单独的中央数据库中。注意，您可以简单地在这个中央数据库中存储一个带有DB名称的字符串（不是所有连接详细信息），详细信息可以在启动时来自某个属性文件（将DB名称映射到连接详细信息）

或者，您可以使用用户凭据查询所有数据库，直到找到“正确”的数据库

这很难说。如果中央数据库仅包含登录信息（以及其他跨组织数据），则特定于组织的数据库仍可能包含特定于组织的数据。例如，它可能有稍微不同的模式，可能需要某种加密，或者每个数据库对用户有不同的访问限制等。我见过一些组织（客户端）的请求，出于安全考虑，它们特别要求这些数据与其他组织“分开”存储

（+4.）您不需要将连接字符串存储在某个中央数据库中来支持此方案。您可以在启动时启动所有组织数据库的连接池，因此无需在（稍后）运行时处理连接详细信息。要考虑的一个大问题是安全性：如果有人能够访问连接细节，会发生什么？他可能会用它从其他数据库检索所有数据。因此，归根结底，这取决于您对连接数据的保护程度，例如，您几乎肯定不希望这些信息未加密地存储在某个数据库中

---

作为您对我的第一个问题的回答的澄清点，是否需要通过检查目标URL来确定数据库？更具体地说，如果web UI是使用MVC用C语言编写的，那么登录代码是否会简单地检查

Request.Url

并根据子域选择DB连接？或者您指的是其他技术？建立数据库连接和使用数据库连接是有区别的。依我看，打开一个连接最好用。当您要连接多个数据库时，每个数据库可能需要一个池。您需要某种方法来确定要与哪个池（即哪个数据库）对话，在我的回答中，我假设您有一些映射“email domain:database name”——这可以存储在您的（中央）数据库中。然后，您将拥有另一个映射“databasename:connectionpool”（基本上是一个hashmap），您将在运行时构建该映射。