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