选择数据库连接

Choosing a DB connection

假设系统

考虑一个公开单个 Web UI 但利用同一数据库模式的多个实例的系统。假设每个用户都属于某个更大的实体,称之为 "organization",并且每个组织都有自己的数据库实例。当用户登录时,系统应该确定使用哪个数据库实例。

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

我的问题如下:

  1. 我的初步评估是否正确,这个假设的系统实际上需要一个中央数据库来将用户登录信息映射到与该用户所属组织对应的连接字符串?
  2. 如果需要一个集中式数据库,这是否必然会破坏每个组织拥有自己独立的数据库实例的目的?
  3. 在数据库中存储连接字符串真的是个坏主意吗?为什么?在数据库中存储连接字符串时应该考虑哪些问题和顾虑?
  4. 将登录信息映射到连接字符串真的是网站知道使用哪个数据库实例的唯一途径吗?还有哪些其他技术?
  1. 不,可能有其他选择,具体取决于用户标识符。例如,如果您使用电子邮件地址来识别用户,并且可以确保每个组织仅使用一组已知(且唯一)的域,则您可以 select 仅在域部分使用正确的数据库。您可以将域数据库信息存储在单独的中央数据库中。请注意,您可以简单地在这个中央数据库中存储一个带有数据库名称(不是所有连接详细信息)的字符串,详细信息可能来自启动时的某个 属性 文件(将数据库名称映射到连接详细信息)。

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

  2. 这很难说。如果中央数据库仅包含登录信息(以及其他跨组织数据),则特定于组织的数据库仍可能包含特定于该组织的数据。例如,它可能有稍微不同的模式,它可能需要某种加密,或者你对每个数据库的用户有不同的访问限制等。我已经看到来自组织(客户)的请求特别要求数据“分开”存储来自其他组织,出于安全考虑。

  3. (+4.) 您不需要 将连接字符串存储在某些中央数据库中以支持此方案。您可以在启动时为所有组织数据库启动连接池,因此您不需要在(稍后)运行 时间处理连接细节。需要考虑的大问题是安全性:如果有人可以访问连接详细信息,会发生什么情况?他可能会用它来检索其他数据库的所有数据。所以它归结为您可以保护此连接数据的程度,例如,您几乎肯定不希望此信息未加密地存储在某些数据库中。