单独或独立的数据库为单独的客户帐户？

我正在研究从智能卡收集数据的应用程序。我希望能够将该应用作为多个客户帐户的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);

现在，如果我把一切都放在一个数据库，这意味着多个账户可以处理相同的CardHolders和SmartCards，但账户不应该看到其他数据。因此，智能卡在帐户中是唯一的，但不在整个数据库中。所以，每一个约束必须包括帐户ID，

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);

在实际的DB，就会有（由expirydate等等等等上市）更表，列和几个指标的载荷和帐户ID列都有处处纳入。

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

来源

2010-12-15 Batibix

在设计多租户应用程序时，有几件事情需要考虑，包括（正如您的问题所述）架构设计，但也应考虑诸如许可证成本，可伸缩性等事宜。包括优点和缺点，包括This article describes the three most common approaches for designing a multi-tenant application。一探究竟。

来源

2010-12-15 12:04:38

标记为答案，因为你的链接给了我最多的信息。我仍然无法决定该怎么做。我将开始为多个租户设计一个数据库，因为如果我改变主意，将其更改为隔离的数据库比将数据库重新设计为一个数据库设计更容易。 – Batibix 2010-12-16 19:28:26

这个链接真的很棒。我学到了很多。它应该是我可能购买的建立Saas的书的一部分。 – racl101 2015-10-21 23:30:04

真的希望你在这里发布这篇文章的肉，因为链接腐烂，现在这是一个死的答案。 – 2017-10-03 18:33:34

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

这不仅会决不能被共享
它还使模式来彼此独立地改变这种完全安全的数据。我的意思是，随着时间的推移，也许一个租户比其他所有的柚木都大，因此必须满足特殊需求。
备份，恢复操作和策略可以很容易地制定了独立的数据库
约束和独特性是更简单，更自然地表达

来源

2010-12-15 12:27:04

我将无法在没有运行的情况下为每个租户提供独立架构进入维护噩梦与分歧的应用程序版本等 – Batibix 2010-12-15 12:42:52

你仍然受益于1 + 3 + 4 – 2010-12-15 12:47:38

是的，尤其是4，因为唯一性在单个数据库中变得非常奇怪。从概念上讲，在单独的数据库中，一切似乎都更有意义。虽然我不确定维护和云托管成本。 – Batibix 2010-12-15 13:08:11

我们已经走了下来这里两条路线。对于那些不需要自定义的小型客户，我们有一个共享数据库，并为企业客户提供了一个单独的数据库（以及针对该问题的应用程序代码库）。

两者都有其优缺点。在共享数据库中，所有需要的都是一个错误的查询，其中有人忘记使用客户端，并将数据暴露给其他客户端。五年来，我看到这种情况只发生过一次，但这是一个让我们成为客户的重大噩梦。如果你走这条路线，确保你有一个好的QA团队，在发布代码之前检查它是否完全符合要求。如果您的数据库具有架构，则可以在架构中使用视图来防止其他客户端数据的数据访问。如果客户只有他们观点的权利，那么他们就不会看到其他人的数据。尽管如此，这是更多的工作。

但是单独的数据库可能成为维护变更的噩梦。但是，如果您销售升级产品，则需要这样做，因为不是每个客户都会购买每次升级。只要确保你有一个好的跟踪机制来知道每个客户端在哪个版本上，并且你使用源代码控制来跟踪所有数据库版本的变化，所以你可以轻松升级。

如果您不打算进行自定义，您可能会发现单独的数据库无论如何都会导致该方向。当他们在一个共享数据库中时，告诉他们不是很容易。

此外，我们发现有些定制对其他客户有帮助，但是由于它们是在单独的应用程序和数据库中开发的，因此不同团队为不同客户重新开发，最终有6种方式做同样的事情。这对于那些将客户数据导入数据库的客户（如客户）工作的人来说是一大痛苦。我个人更喜欢一种数据库方法。

关于整合或分离需要关注数据报告的另一点。如果报告只能由客户完成，那么您可以将它们分开，但如果您需要报告（例如您自己的内部财务报告）以确定合并数据，那么如果您拥有统一数据库，则会更容易。我提出这个问题是因为人们往往会在设计完成之后才会忘记报告，当你这样做的时候会导致一些相当不好的问题。

来源

2010-12-15 14:37:49 HLGEM

如果你有一个使用配置文件来设置数据库的工具，这个问题就变得不那么重要了 – 2010-12-15 14:48:26

单独或独立的数据库为单独的客户帐户？

回答

相关问题