出于“安全”原因，每家公司都有一个数据库

Question

可能重复: 为50.000+商店使用一个数据库是个好主意吗？

我们正在用MVC 4开发一个C#的互联网应用程序，它连接到一个数据库，该数据库将包含一个公司、客户和他们的服务，以及产品。

当然，这些公司希望他们的数据是安全的，而且这些数据也需要尽快从数据库带到web应用程序。

我们不知道什么是最安全和最有效的方法：

1. 为每个公司建立一个较小的数据库，其中包含客户数据。这样，唯一的“弱”人工链接就是根据登录的人来对连接字符串进行正确的编码。
2. 使用一个包含每个公司数据及其所有客户数据的单一数据库。这将自然是一个非常大的数据库，并有可能(？)更多的错误空间，导致一名员工看到另一家公司的失误。危急的情况。

什么样的解决方案可能是最安全的，并且在处理数字并处理到web应用程序中最快？这是一个常见的“安全”解决方案，通过给每个公司自己的数据库来最小化人为错误吗？

Answer 1

您的安全需求似乎超过了您的性能考虑(否则您不会将此部分称为“关键”)。

一些一般性意见(但请参阅更多细节)：

1. 保持数据的分离似乎是最重要的。在连接字符串方面，没有弱的人工链接。您可以将客户端信息存储在中央数据库中，包括要连接到的服务器/数据库，应用程序代码/中间层根据选择的客户端(可以绑定到凭据等)构建连接字符串。
2. 就性能而言，搜索一个客户数据的表比搜索包含每个人数据的大型表要高效得多。您也可以非常容易地将50,000个客户端与他们自己的数据库划分到多个服务器上，而不是试图在一个服务器上的一个实例中实现所有这些。很难用一个单一的单块数据库来扩展读/写。
3. 单独的数据库使您能够将不同的客户放置在不同的SLA (例如，他们的数据库可以在更快的存储上)和HA/DR (完全恢复相对简单，镜像/复制/日志传送等的数据较少，日志备份的不同频率等)。它们还允许您将一个客户端恢复到某个时间点，而不让其他人回到同一时间点。

但是，我不知道.sdf方法的发展方向。对于50,000个数据库，您应该有适当的Server实例，并将真正的数据库附加到这些实例中，而不是这种基于文件的紧凑型版本胡说八道。国际水文学组织。