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