单独数据库中的用户表

Question

注意：我无意实现这一点，它更像是一个思想实验。

假设我通过Web界面提供了多项服务。其中至少有两个需要用户注册和数据库中的一些数据。单一注册将授予对所有服务的访问权限。像Google（GMail，Google Docs等）。

与注册用户相关的所有这些服务是否都位于单个数据库中，可能使用表格前缀来表示他们所使用的服务？

或者每个服务都有自己的数据库吗？我可以看到这样做的唯一好处是它可以使表名更清晰。每当需要任何用户交互时，都需要与至少两个不同的数据库进行交互，这将不必要地使sql查询复杂化。

这是否表明“大男孩”只使用一个数据库，并加载了大量不同（可能完全不相关）的表格？

Answer 1

我认为将多个服务依赖于单个数据库并不是一个好主意。如果您需要从备份中恢复某些服务，则必须还原所有服务。 您可能也在重载数据库服务器。 只有在未来可能会分享大量数据时，我才会这样做。

您也可以考虑只使用共享用户数据的较小数据库。

Answer 2

我会考虑为一个用户/角色存储库提供一个单独的服务数据库。

Answer 3

如果您使用正确的DBMS，您可以充分利用这两种策略。在PostgreSQL中，在“数据库”中，您可以使用单独的模式。身份验证服务将访问单个模式，并为其他服务提供一个密钥，该密钥用作其他模式中数据的引用。您仍然可以将整个数据库作为单个实体处理，即：

• 跨模式查询而不使用dblink
• 单独存储个人身份信息（模式可以具有单独的每用户权限以进一步保护数据）
• DBMS管理的外键约束（我相信）
• 一致（重新数据）备份和恢复

您可以通过更复杂的DAL（您最喜欢的DAL框架可能不支持）以及DBMS之间的可移植性更低来获得这些优势。

Answer 4

我从未这样做过，但我认为这取决于性能。如果几乎没有开发单独数据库的开销，那可能就是答案。执行单独的DB还可以轻松地跨机器拆分DB。

复杂性也是一个问题。希望您的架构将以这样的方式定义，即您不需要为不同的查询进入几个不同的数据库。

Answer 5

数据库及其访问权限可能会出现问题;复制是一个很好的解决方案。

Answer 6

有几种策略。

当您迁移到多个数据库（或多个服务器）时，事情变得更加复杂。您的核心用户信息可以位于单个数据库中。各个服务可以在其他数据库中。问题在于数据库是引用完整性的外部单元，因此您无法跨数据库设计外键。解决此问题的一种方法是将更改分发到核心主表（显然是添加和更新，因为由于外键约束而禁止删除）以定期分离数据库，然后针对这些副本强制执行RI服务数据库中的核心主数据库表。这也意味着服务数据库及其服务可以在其他数据库关闭以进行维护时运行。显然，这会增加架构的复杂性，以改善服务窗口并减少耦合。

我建议从单个数据库开始。如果您的RDBMS支持它，我会根据SCHEMA组织组件，这将允许您至少通过设计保持逻辑分离。您可以在以后更轻松地进行重构。

许多数据库都有可以被视为无关的表。有时在系统中，您有多个实体网络很难连接（有时根本不连接）。您也可以在这些情况下使用SCHEMAs。