我们正在新架构上设计现有产品的新版本。 它是一个内部Web应用程序，可能有100个并发用户（最大）这将在SQL Server 2008数据库上运行。
最近的讨论项目是我们是否应该有一个单独的数据库，以便在两个不同的数据库中出于性能原因拆分数据库。
数据库可以在5年内从50-100GB增长到任何地方。
我们是开发人员，而不是DBA，因此获得一些一般性指导会很好。
[我知道答案并不简单，因为它取决于架构，存档政策，数据量等。]
选项1单个主数据库 [这是我的首选]。
计划是将所有表都放在一个数据库中，如果需要跨多个磁盘，可能需要使用文件组和分区来分隔数据。 [如果合适，使用架构]。这应该处理性能问题 其中一条评论是，单个服务器实例仍然会处理这些数据，因此仍然存在处理瓶颈。
对于报告，我们可以有一个单独的报告数据库，但仍在讨论中。
选项2将数据库拆分为2个单独的数据库
DB1 - 客户，客户，客户资源等
DB2 - 这将包含大量数据[即车辆跟踪数据，金融交易表等]。
这些表通常包含大量数据。 [如果需要，它可以驻留在单独的服务器上]
此计划将涉及将主数据保存在较小的数据库[DB1]中，并将[主要]只读事务类型数据保留在单独的DB [DB2]中。 UI主要从DB1读取，因此响应更快。 [我知道这个选项会使参考完整性更难实施。]
考虑点 当我们处于设计阶段时，我们至少可以正确使用索引来处理性能问题，这就是为什么选项1对我有吸引力而且更多的是标准方法。 对于这两个选项，我们正在考虑实施归档数据库。
长期问题道歉。总之，问题是1 DB还是2？
提前致谢，
利安
答案 0 :(得分：5)
我认为选项1是要走的路。
CPU不太可能成为您提供工作负载的100个并发用户的瓶颈。您可以通过热插拔技术获得具有额外CPU容量的单个多插槽服务器，以便根据需要提供增长空间。根据您的可用性要求，您还可以考虑使用群集解决方案，以允许通过强制故障转移到另一个节点来交换更多处理CPU资源。
您的磁盘子系统的性能将是您最关心的问题。您的设计决策将受到您使用的存储解决方案的影响，我认为这将是SAN技术。
至少，您需要将LOG（RAID 1）和DATA文件（RAID 10或5取决于工作负载）放在不同的LUN上。
根据您的表访问权限，您可能希望考虑将不同的文件组放在单独的LUN上。对表格数据进行分区可能对您有利，但仅适用于大型表格。
答案 1 :(得分：2)
今天大多数标准都是50到100GB和100个用户是一个非常小的数据库。不要通过尝试解决您尚未看到的问题来过度设计解决方案。将它分成两个数据库，尤其是在两个不同的服务器上会产生一大堆令人头疼的问题，你最好不要这样做。集中精力创造有用的产品。
答案 2 :(得分：2)
我同意其他评论说这些天50到100GB之间很小。我也同意你不应该过度工程。
但是，如果您存储的实体之间存在明显（或不那么明显）的逻辑分离（就像您说的那样，一个是读写而其他部分主要是只读的），我仍然将它分开不同的dbs。至少我会以一种我很容易将一件作品计算出来的方式来设计它。安全性是一个原因，管理/备份/恢复另一个，更容易的可维护性（因为本质上设计将更好地考虑因素并且部件彼此更好地隔离），并且，在SQL Server中，能够扩展（或者如果它缺乏）是一个单一的数据库）。例如，分离登录和内容数据库通常对更大的Web应用程序有意义。
而且，如果你真的想要一个声音设计，在一个数据库中分离你的实体，使用不同的模式，对对象赋予适当的权限，你最终会在我眼中完成相同的工作。
像SharePoint，TFS和BizTalk这样的Microsoft产品都使用了几个不同的数据库（虽然我不会假装知道原因/可能只是他们组织团队的方式的结果）。
特别是关于你无法在SQL Server上扩展单个数据库实例（集群需要多个实例），我很想分割它。
@John：我从不使用RAID5。除了损害性能之外，没有任何其他目的。我同意RAID10方法。
答案 3 :(得分：1)
将数据放在另一个数据库中不会对性能产生丝毫影响。性能完全是其他因素的一个因素。
创建新数据库的原因是出于维护和管理原因。例如，如果一组数据需要不同的备份和恢复策略，或者具有更高的可用性要求。