什么是最好的，一个大型 SQL 数据库、多个较小的数据库或多个较小的表？答案

【问题标题】：Whats best, one large SQL Database, multiple smaller ones, or multiple smaller tables?什么是最好的，一个大型 SQL 数据库、多个较小的数据库或多个较小的表？
【发布时间】：2019-01-31 15:06:06
【问题描述】：

我即将重建一个在线服务，该服务使用单个 SQL Server 2016 数据库来管理拥有大约 40k 会员的数百个俱乐部。它目前运行良好且快速。然而，该系统很快就会在俱乐部和会员中翻两番。这意味着一个包含 16k 个成员的成员表和其他记录比成员多得多的表（即出勤记录等）。为每个俱乐部创建一个数据库（可能有大约 1200 个数据库）或为所有人保留一个数据库会更有效吗？或者为每个俱乐部创建单独的表格会更有效？（不需要俱乐部之间的数据交互）

【问题讨论】：

16k 行至少可以说是微不足道的。 SQL Server 可以轻松处理单个表中的数百万行。如果目前运行良好且快速，为什么要首先尝试重新设计它？这听起来像是过早的优化，这是使用非标准设计模式来解决不存在的性能问题的做法。这也是纯粹的邪恶。在我看来，您应该不理会它，并在您实际遇到性能问题时解决这种情况。但是......每个俱乐部的单独桌子听起来真的很可怕。
我更喜欢具有精心设计的索引和查询的单一数据库。索引的存在是为了确保更大的数据库不会被占用。此外，我不喜欢为不同的团体（俱乐部等）制作类似表格的做法 - 为什么不使用一个带有“ClubID”的表格 - 比 tabClub1、tabClub2、.....
这是一个常见问题解答。例如，谷歌你的标题。

标签： sql-server database-design

【解决方案1】：

管理 1200 个数据库将是一场噩梦。

如果俱乐部的数据相似，则所有俱乐部只能有一张表。

为了分离数据，您可以创建 1200 个视图以仅显示单个俱乐部。

此外，对于其他报告目的，使用存储过程会很方便。每个报告一个，以组名作为参数。例如：

EXEC sp_Club_Attendance @ClubName = 'ABC Heroes';
EXEC sp_Club_Annual_Budget @ClubName = 'XYZ Pilots';

【讨论】：

【解决方案2】：

可能有一些 DBA 对此有强烈的意见（我不是 DBA），但我个人不想管理 1200 或更多的数据库。根据成员表中行的大小，您可以轻松地在其中容纳数百万或数十亿条记录。在这方面，大小不应该是一个问题。只要对数据库进行了适当的规范化，我就可以将其保留为一个数据库。在做出这样的决定时，应考虑各种因素。管理 1200 个数据库的备份/恢复或灾难恢复的效率如何？实际创建 1200 个数据库的效率如何？管理 1200 个完全（或几乎完全）就模式相同的不同数据库有多容易，唯一的区别是它们中的数据？

【讨论】：

我对此有强烈的意见！人们出于错误的原因走上了多数据库路线。我的公司这样做是因为担心公司会因为错误而看到其他公司的数据。担心实际上小到可以放入手机的大型数据库。希望能够检索数据库以进行调试（创建一种提取匿名数据的方法很简单）。希望能够定制，但随后启动了一个使所有定制数据库相同的程序。