用于单独客户帐户的单个或单独数据库？

Question

我正在开发一个从智能卡收集数据的应用程序。我希望能够将应用程序作为多个客户帐户的 Web 服务运行。问题是，我应该为每个帐户创建一个单独的数据库，还是应该设计一个包含所有帐户数据的数据库？首先，我认为单个数据库是显而易见的答案，但它导致 AccountID 必须在表、索引、约束、查询、检查等几乎任何地方使用。

在这个应用程序中，帐户之间不共享任何字节的数据。

首先，让我们看看一个帐户的单独数据库是什么样子的：

CREATE TABLE CardHolder ( 
    CardHolderID int, -- primary key
    CardHolderUniqueName nvarchar(30) );

CREATE TABLE SmartCard (
    SmartCardID int, -- primary key
    CardHolderID int,
    CardUniqueName nvarchar(30) );

添加一些唯一性约束，

ALTER TABLE CardHolder ADD CONSTRAINT UQ_CardHolderName UNIQUE (CardHolderUniqueName);
ALTER TABLE SmartCard  ADD CONSTRAINT UQ_CardName UNIQUE (CardUniqueName);

现在，如果我将所有内容放入一个数据库中，则意味着多个帐户可以处理相同的持卡人和智能卡，但帐户应该看不到对方的数据。因此，智能卡在一个帐户内是唯一的，但在整个数据库中不是唯一的。因此，每个约束都必须包含一个 AccountID，

CREATE TABLE CardHolder ( 
    CardHolderID int, -- primary key
    CardHolderUniqueName nvarchar(30),
    AccountID int );

CREATE TABLE SmartCard (
    SmartCardID int, -- primary key
    CardHolderID int,
    CardUniqueName nvarchar(30)
    AccountID int );

ALTER TABLE CardHolder 
    ADD CONSTRAINT UQ_CardHolderName UNIQUE (AccountID, CardHolderUniqueName);
ALTER TABLE SmartCard
   ADD CONSTRAINT UQ_CardName UNIQUE (AccountID, CardUniqueName);

在实际的数据库中，将会有更多的表、列和多个索引（用于按到期日期等列出），并且 AccountID 列必须包含在任何地方。

对我来说，这似乎有点混乱，首先将所有帐户放入一个数据库中，然后通过在每个表以及几乎每个约束和索引中都有一个 AccountID 列来分隔它们。我还需要找到或发明某种行级安全性，以防止用户访问其他帐户的数据。那么，我是否有一个有效的借口为每个帐户创建一个单独的数据库，或者“真正的数据库设计者”总是将所有内容保存在一个数据库中？

Answer 1

设计多租户应用程序时需要考虑几件事，包括您的问题所述的架构设计，但还应考虑许可证成本、可扩展性等因素。 本文介绍了设计多租户应用程序的三种最常见方法，包括优点和缺点。一探究竟。

链接到该文章的 pdf 版本： http ://ramblingsofraju.com/wp-content/uploads/2016/08/Multi-Tenant-Data-Architecture.pdf

Answer 2

恕我直言，只有一种方法。多个数据库。

1. 这不仅完全保护了绝不能共享的数据，
2. 而且还使模式能够彼此独立地更改。我的意思是，随着时间的推移，也许一个租户比所有其他租户都大得多，因此必须满足特殊需求。
3. 可以轻松地为独立数据库制定备份、恢复操作和策略
4. 约束和唯一性更容易、更自然地表达

Answer 3

我们在这里两条路都走了。我们为不需要定制的小型客户提供了一个共享数据库，为需要定制的企业客户提供了一个单独的数据库（以及与此相关的应用程序代码库）。

两者都有其优点和缺点。在共享数据库中，只需要一个错误的查询，即有人忘记使用 clientid，数据就会暴露给其他客户端。五年来，我只见过这种情况发生过一次，但这是一场重大噩梦，导致我们失去了一个客户。如果您走这条路，请确保您有一个优秀的 QA 团队，在将代码发布到产品之前准确检查这一点。如果您的数据库有架构，您可以在架构中使用视图来防止其他客户端数据的数据访问。如果客户只拥有自己观点的权利，那么他们就永远看不到其他人的数据。不过，这需要更多的工作来设置。

但单独的数据库可能会成为进行维护更改的噩梦。但是，如果您出售升级，则应采用这种方法，因为并非每个客户都会购买每个升级。只需确保您有一个良好的跟踪机制来了解每个客户端所在的版本，并使用源代码控制按版本跟踪所有数据库更改，以便您可以轻松升级。

如果您不打算进行自定义，您可能会发现拥有单独的数据库无论如何都会导致这个方向。当他们位于共享数据库上时，告诉他们“不”要容易得多。

此外，我们发现有些定制对其他客户会有帮助，但因为它们是在单独的应用程序和数据库中开发的，所以它们会由不同的团队针对不同的客户重新开发，最终您有 6 种方法可以做到这一点事物。对于跨客户端工作的人员（例如将客户端数据导入数据库的人员）来说，这成为一个主要的痛苦。我个人更喜欢单一数据库方法。

关于合并或分离的需要的另一点涉及数据报告。如果报告始终仅由客户完成，那么您可以将它们分开，但如果您需要使用合并数据进行报告（例如您自己的内部财务报告），那么如果您有一个统一的数据库，那就容易得多。我提出这个问题是因为人们往往会忘记报告，直到设计确定之后，当你这样做时可能会导致一些非常讨厌的问题。