我加入了一家小公司，主要销售一个网络应用程序。 Web应用程序中的数据非常敏感，所有数据都是字段级加密的。应用程序是用ASP.NET Web API 2（C＃）编写的，带有html / javascript前端和SQL-Server。
目前，他们有大约50个客户端，应用程序的架构是每个客户端都有自己的数据库。它们都部署到自己的IIS虚拟目录中，然后指向其自己的数据库。所有客户端的代码完全相同。
店主告诉我，这完全是出于安全考虑。然而，管理是一种绝对的痛苦，而且他们只会获得更多的客户。
我建议将它们全部合并到一个数据库中，并在主表上添加一个字段，用于标识数据所属的客户端。从这里我可以过滤/加入该领域。
所有者不喜欢这样，因为它引入了风险：如果存在伪劣代码，则一个客户端可能能够看到另一个客户端数据。这显然不会发生在多个数据库中，因为连接字符串不会与不同的数据库交叉。
有没有办法降低风险呢？我建议覆盖授权类以阻止未经授权的用户访问信息，但这并不能解决整个“错误代码”问题。问题
我能做些什么，还是我不能维护一大堆数据库？
答案 0 :(得分：3)
目前的设置也存在风险。如果有人混淆了网站上的数据库连接字符串怎么办？你必须确定哪个风险更大。
如果你决定保留单独的数据库，听起来你需要投资自动化来帮助管理它们。我们使用Database项目来源控制数据库模式/脚本和MSDeploy，以自动部署到所有数据库。也许这会通过多个数据库提升你的一些痛苦。
http://dotnetcatch.com/2016/02/10/deploying-a-database-project-with-msdeploy/
答案 1 :(得分：3)
我认为这里没有正确或错误的答案，这完全取决于给定公司（或其所有者）的风险偏好。
连接字符串指向错误的数据库似乎不太可能比编写意外（或有意）从单个数据库中提取其他公司数据的代码。
除了安全性之外，独立的数据库体系结构提供了超过共享数据库的一个巨大优势：这是数据的恢复。如果您只需要还原单个客户端的数据，则单独的数据库设计允许您以不影响其他客户的方式执行此操作。如果是共享数据库，任何恢复过程都会影响其他客户端的服务。
单独的数据库和共享数据库之间可能存在中间立场：单独的架构。如果使用此方法，单独的模式仍然保持一定程度的分离，但是要管理的数据库实例要少得多，因此服务可以更好地扩展。
MSDN上有一篇很好的文章介绍了所有3个选项：Multi-Tenant Data Architecture。 artice描述了所有3种场景的优缺点。
然而，请记住，这一切都取决于贵公司的主观风险偏好！