这不是关于我遇到的特定问题，但我必须澄清一些事情，因为我与这个项目有很多风险。
我正在创建一个 Web 应用程序，该应用程序将部署到英国的一些大公司，如果我们弄错了，我们可能会付出巨大的代价！
我需要确保每个公司的数据都非常安全，所以我想知道为每个组织创建一个新数据库是否是个好主意，这样他们的数据是完全独立的，如果一个数据库被破坏，所有组织的数据不会受到影响 - 这将使我们有时间在所有数据受到损害之前对安全问题做出反应。我的问题是：
提前致谢
我假设这是一个关于为“软件即服务”风格的应用程序构建“多租户架构”的问题。
第一个问题是分离数据库可能是一个好主意，也可能不是一个好主意——但这不是第一个要问的问题。可以在重要级别访问您的数据库的人已经以极具破坏性的方式渗透到您的应用程序 - 他们几乎可以肯定地在您的数据库服务器上执行任意命令。这意味着您不仅要处理一个帐户的损坏，还要处理整个基础架构的损坏。这是一个“熄灯”的时刻，您必须在恢复时关闭整个系统。
如果他们没有在您的数据库服务器上建立外壳，则意味着存在应用程序层安全问题 - SQL 注入，或者在您的身份验证方案中升级权限的某种方式。同样，两者都是“熄灯”时刻。
所以，确保所有这些东西都被完全覆盖。在您的开发生命周期中包括安全测试；考虑使用自动化渗透测试工具作为持续集成系统的一部分。确保基础设施人员强化整个环境，并在接近发布候选时考虑进行第 3 方安全审计。考虑一个专注于安全问题的代码审查过程，并就特定的安全考虑因素达成一致的编码标准。告诉您的所有开发人员有关跨站点脚本、SQL 注入和其他应用程序级漏洞的信息。
一旦你完成了所有这些，你就锁上了门并栓上了窗户；您的数据库策略相当于您如何保证珠宝的安全。
单独的数据库提供了一些额外的安全性——但前提是您有相应的用户管理策略。在大多数网络应用程序中，只有两种类型的用户：“管理员”和“网络应用程序”。“管理员”可以创建/修改数据库（创建数据库、表、视图等），通常还可以修改数据。“Web 应用”应该只有数据修改权限，而没有修改数据库对象的权限。
为了使数据库拆分有意义，您必须确保：
但是，拆分数据库还有其他原因（除了安全性之外）。它降低了人为错误的风险，允许您在更细粒度的级别扩展系统，并允许您提供不同级别的托管（“黄金”用户拥有自己的服务器，“白银”用户拥有自己的数据库，“青铜” “抓住他们的机会）。
要实现这一点，您必须解决的大问题是部署——您将如何部署新版本的代码以及对数据库的更改？这反过来又可能使测试过程复杂化。
几乎可以肯定的是，独立的数据库。正如@Anigel 所说，甚至可能是单独的服务器，尽管其管理和成本更复杂，因此将取决于您的确切要求。
一个好处是，在未来的某个时候，也许一个客户端的数据会变大，因此更容易拆分到新服务器，或者他们可能会升级您的平台，但另一个没有。
如果您可以转储/加载整个数据库，而不是挑选所有名称以clientX_开头的表，则备份和恢复会更容易。
在单独的数据库上进行性能测量会更容易。
只需几个快速的想法即可开始。
@Lee Price，为每家公司维护单独的数据库将是一件好事。
好处：
它将确保您的数据库安全
在很长一段时间内，当桌子的大小仅限于一家公司时，这会给您带来激烈的表现。操作会很快。
易于明智地操纵数据公司。
在支持方面提供帮助
缺点：
需要跟踪每家公司的架构更改
维护单独的数据库
维护单独的备份
与单个数据库相比，占用更多空间
但我个人建议您为每家公司使用单独的数据库。