但是，我们正在开发一个新系统，它将拥有50-100个客户端，也许还会更多。我认为在这种情况下，每个客户端只有一个数据库（存储敏感记录和审核历史记录）可能是不可行的。但是，我不知道这是否完全正常，还是存在另一种维护安全性的方法。
对此有何想法？
#1 楼
实际上，管理100或500个数据库与管理5或10个数据库并没有什么不同-您只需要接受自动化并制定可扩展性计划（并且不打算使用跨数据库的高成本每数据库功能客户）。在我上一份工作中，我们使用了这种体系结构，即使有些挑战可能是“艰巨的”，我也从未想过将两个客户端合并到一个数据库中。
最大的好处是独立的恢复模型（
a可以很简单，b可以是完整的，等等），能够在不中断其他客户的情况下恢复到某个时间点（或完全删除），能够以很少的透明性无缝地将资源繁忙的客户端无缝移动到其自己的存储或完全不同的服务器上（您可以更新配置文件或表来告知应用程序在哪里找到该客户端）。 > 我在以下帖子中解决了一些异议和/或如何解决问题：
在多租户数据库体系结构中处理越来越多的租户
/>使用SQL Server 2008的多租户数据库？
自动备份大量数据库管理对您来说变得不切实际-只要知道遇到任何具体挑战，就可以单独询问这些问题。
#2 楼
我建议您阅读Multi-Tenant Data Architecture，该白皮书讨论了您的选择以及优缺点。总之，它提供了三个选项：分离的数据库
分离的模式
共享的模式
您现在处于分离的DB阶段，它提供了最佳的隔离（租户之间的隔离），但最难管理。当您成长为成百上千的租户时，您将意识到管理100个DB的后勤工作并非易事。考虑备份还原（备份文件的位置，作业，日程表等）。想想如何在数百个数据库中监视和管理文件分配，已使用的磁盘空间以及数据库的增长。想一想在不久的将来有1000个租户的情况下，您的高可用性/灾难恢复方案将是什么？ 1000个镜像数据库，1000个日志传送会话？想想如果您的开发团队在6个月内遇到您，并说“我知道如何为我们的产品提供这一出色功能，我们将使用事务复制！”，您会怎么说？ “当然，让我建立500个发行商，这将很有趣”！管理数百个数据库并非不是不可能，但是如果您计划的话，则可以更好地增强PowerShell技能并立即停止使用UI管理工具。数据库对性能和成本的影响可衡量： ）
您无法创建用于记录大量任务的专用日志磁盘，您将不得不将所有这些LDF移至一个（或多个）SSD存储上。
日志写入的效率较低频繁提交，因为它们分布在许多单独的日志块记录中，然后汇总成一个（您将得到未充分使用的日志块）。请参阅什么是LSN：日志序列号以了解我在说什么。
尽管由于隔离，分离的DB也具有一些优势，主要优势是独立的备份/还原。像您这样的方案是SQL Azure数据库的理想选择。无需管理磁盘空间，无需提供HA / DR，可扩展到成百上千的DB等。
#3 楼
在我之前的工作中，我们为每个客户端不仅托管一个数据库，而且在大多数情况下，托管的数据库还不止于此！在我离开时，在一个MariaDB集群中运行着4,500多个数据库，在另一个（具有讽刺意味的是，较小的）集群中运行着近7,000个数据库，以及4个“分片”（完全独立的独立Web和数据库服务器，甚至在一个完全独立的数据中心中），每个主机单个MySQL服务器中包含200-500个数据库。而且该公司仍在快速发展。总而言之，就是该公司的成功证明了这种架构确实是可行的。 （注意：与通过使用单独的数据库单独获得明显的收益相反，所有数据都是通过三个紧密耦合的应用程序访问的，这些应用程序都使用相同的数据库用户/密码！我怀疑如果每个客户端的性能可能会受到轻微影响有一个单独的用户/密码-但只有一点。）
根据我与系统管理员紧密合作的经验（从技术上讲，我是公司的一名程序员，但实际上，我是他们拥有的最好的DBA ，以及他们唯一知道如何设置防火墙的人！服务器上数据库的数量没有明显的作用，这一结论得到了我们定期咨询的高薪专业顾问的肯定。基础架构，而不是数据库数量你碰巧有。所有其他这些因素将足以让您忙于解决性能问题和瓶颈。
评论
您可能会读到此书，特别注意日期和操作注释：stackoverflow.com/questions/5596755/…