单独数据库中的用户表

Question

注意：我没有实施这个想法的意图，这只是一个思维实验。

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

所有这些与注册用户相关的服务是否都位于单个数据库中，也许使用表前缀来区分不同的服务？

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

这是否表明“大公司”只使用一个数据库，并将其加载到许多不同（也许完全不相关）的表中？

- nilamo

---

迄今为止，我喜欢这些答案，因为它们符合我的思路，但与我预期听到的相反。 - nilamo

Answer 1

我认为让多个服务依赖于单个数据库并不是一个好主意。如果你需要从备份中恢复某个服务，那么你必须恢复所有服务。 这样可能会导致数据库服务器过载。 只有当它们在未来的某个时候很可能共享大量数据时，我才会这样做。

此外，您可以考虑只使用包含共享用户数据的较小数据库。

- EFraim

---

在这种情况下恢复数据的一致性是另一个挑战。 - Dana the Sane

Answer 2

我建议将1个用户/角色存储库与服务的单独数据库分开。

- Cody C

Answer 3

如果您使用正确的数据库管理系统，您可以同时拥有最佳策略。在PostgreSQL中，您可以在“数据库”中拥有单独的模式。认证服务将访问单个模式并为其他服务提供一个密钥，该密钥用作其他模式中数据的引用。您仍然可以将整个数据库视为单个实体，即：

- 不使用dblink跨模式查询 - 将个人身份信息分开存储（模式可以具有单独的每个用户权限以进一步保护数据） - DBMS管理的外键约束（我相信） - 一致（关于数据）备份和还原

您可以以更复杂的DAL成本获得这些优势（可能不受您喜欢的DAL框架支持），并且在不同的DBMS之间移植性较差。

- Dana the Sane

---

听起来很酷。我所有的经验都是与SQL Server和/或MySQL相关的，所以我需要更深入地了解这个。 - nilamo

这也适用于SQL Server 2005及以后版本。 - Jason Musgrove

经过一些阅读，这似乎是最佳解决方案，因为它采用了每种不同方法的最佳部分。一方面，所有表格可以分组到与其服务相关的模式中，提供了清晰和逻辑的组织。另一方面，这些数据虽然分离，但也很容易访问和交叉引用，而无需使用多个查询。谢谢Dana。 - nilamo

Answer 4

我从未尝试过这样做，但我认为这取决于性能。如果分开使用数据库几乎没有额外负担，那么这可能是答案。分开使用数据库还可以轻松地将数据库分配到不同的机器上。

复杂性也是一个问题。希望您的模式定义方式能够使您在不同查询中不需要深入多个不同的数据库。

- Chris Simmons

Answer 5

在数据库和访问方面，潜在的过载问题总是存在的；复制是一个潜在的好解决方案。

- Paul Sonier

Answer 6

有几种策略可供选择。

当您转移到多个数据库（或多个服务器）时，事情变得更加复杂。您的核心用户信息可能在单个数据库中。各个服务可能在其他数据库中。问题在于，数据库是参照完整性的外部单位，因此您无法跨数据库设计外键。解决这个问题的一种方法是定期将对核心主表的更改（仅添加和更新，显然，由于外键约束，删除将被禁止）分发到单独的数据库中，然后在服务数据库中针对这些核心主数据库表的副本执行RI。这也意味着服务数据库及其服务可以在其他数据库进行维护时运行。显然，这增加了架构复杂性，但可以提高服务窗口和降低耦合度。

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

许多数据库具有可以视为不相关的表。有时在系统中，您有多个实体网络几乎没有连接（有时根本没有）。在这些情况下，您也可以使用SCHEMA。

- Cade Roux