我被要求开发一个应用程序，该应用程序将运行到许多业务部门。每个单元的应用程序基本相同，但会有轻微的程序差异，这不会改变底层数据库的结构。我应该为每个业务部门使用一个数据库，还是为所有部门使用一个大型数据库？业务部门完全独立
答案 0 :(得分：2)
我的偏好是每个客户一个数据库。优点：
如果客户端太大，他们很容易移动 - 备份，恢复，更改连接字符串，繁荣。当他们的数据与大型数据库中的其他人混合时，请尝试这样做。即使您使用模式和文件组进行隔离，移动它们也不是一件好事。
ditto在移动时删除客户的数据。
根据定义，您将每个客户的数据分开。这往往是一种需求，有时甚至是一种需求。有时它甚至会具有法律约束力。
数据库中的所有代码都比较简单 - 它不必包含客户端的模式（不能参数化），并且您的表不必充满额外的列，表明客户端。
很多人会声称管理200或500个数据库要比管理10个数据库困难得多。根据我的经验，这并没有什么不同。您可以构建自动化脚本，错开索引维护和备份作业等脚本。
潜在的缺点是当你进入每个实例的4位数和更高数据库的领域时，你想要开始考虑拥有多个服务器（阈值真的取决于工作负载和硬件，所以我是只是选一个数字）。如果您构建正确的系统，添加第二台服务器并将新数据库放在那里应该非常简单。同样，应用程序应该知道每个客户端的连接字符串，并且您通过使用不同服务器所做的所有事情都在改变连接字符串指向的实例。
关于dba.SE的一些问题你应该看一下。它们不仅仅与SQL Server有关，但许多概念和挑战都是普遍存在的：
https://dba.stackexchange.com/questions/7924/one-big-database-vs-several-smaller-ones
答案 1 :(得分：0)
您的问题是一个设计问题。为了回答这个问题，您需要了解要构建的系统的要求。从技术角度来看，SQL Server - 或者实际上任何数据库 - 都可以处理任何一种情况。
以下是需要考虑的一些事项。
第一个问题是您的客户需要分离数据的方式。在某些情况下（例如，银行的投资方和市场分析方），将来自不同业务单位的数据混合在一起可能并不合法。在这种情况下，单独的数据库就是解决方案。
下一个问题是安全问题。在某些情况下，客户可能会非常不舒服，因为他们知道他们的数据与其他客户数据混杂在一起。无意中共享了一个小的漏洞和机密信息。对于同一家公司的不同业务部门而言，这可能不是问题。
您是否需要处理不同的正常运行时间要求，上传要求，自定义以及可能与其他工具进行交互？如果一个业务部门需要其他业务部门不感兴趣的自定义，则建议使用不同的数据库。
另一个考虑因素是表现。这个应用程序是否使用了大量昂贵的资源？如果是这样，那么能够在不同的数据库（可能是不同的服务器）上对应用程序进行分区可能是非常需要的。
另一方面，如果共享大部分数据，并且存储库实际上是具有相同底层功能的中央存储库，那么一个数据库是一个不错的选择。