这个问题与另一个问题有关：
Will having multiple filegroups help speed up my database?
我们正在开发的软件是一种分析工具，它使用MS SQL Server 2005来存储关系数据。初步分析可能很慢（因为我们正在处理数百万或数十亿行数据），但是快速调用以前的分析存在性能要求，因此我们“保存”每个分析的结果。
我们当前的方法是将分析结果保存在一系列“特定于运行”的表中，并且分析非常复杂，每次分析最多可能有100个表。通常，这些表每次分析耗尽几百MB（与我们的数百GB，有时甚至是多TB的源数据相比，这个表很小）。但总的来说，磁盘空间对我们来说不是问题。每组表都特定于一个分析，在许多情况下，这为我们提供了超过回溯源数据的巨大性能改进。
一旦我们积累了足够的保存分析结果，这种方法就会开始崩溃 - 在我们添加更强大的归档/清理功能之前，我们的测试数据库已经攀升到几个百万表。但即使在生产中，我们也不能拥有超过100,000张桌子。微软对sysobjects的大小（约20亿）进行了相当大的理论限制，但是一旦我们的数据库增长到100,000以上，像CREATE TABLE和DROP TABLE这样的简单查询就会大大减慢。
我们有一些空间来讨论我们的方法，但我认为没有更多的背景可能很难做到，所以相反我想更普遍地提出这个问题：如果我们被迫创造这么多的表，那么什么是最好的管理它们的方法？多个文件组？多个架构/所有者？多个数据库？
另一个注意事项：我对于“简单地将硬件投入问题”（即添加RAM，CPU功率，磁盘速度）的想法并不感到兴奋。但我们也不会排除它，特别是如果（例如）某人可以明确地告诉我们添加RAM或使用多个文件组对管理大型系统目录会产生什么影响。
答案 0 :(得分：2)
在没有首先看到整个系统的情况下，我的第一个建议是将历史运行保存在组合表中，并将RunID作为键的一部分 - 维度模型也可能与此相关。可以对此表进行分区以进行改进，这也允许您将表扩展到其他文件组中。
另一种可能性是将每次运行放在自己的数据库中然后分离它们，只根据需要附加它们（以只读形式）
CREATE TABLE和DROP TABLE可能表现不佳，因为主数据库或模型数据库未针对此类行为进行优化。
我还建议您与Microsoft讨论您选择的数据库设计。
答案 1 :(得分：1)
表格是否都是不同的结构？如果它们是相同的结构，您可能会使用单个分区表。
如果它们是不同的结构，但只是同一组维度列的子集，您仍然可以将它们存储在同一个表中的分区中，并且在不适用的列中使用空值。
如果这是分析（衍生定价计算可能？），您可以将计算运行的结果转储到平面文件，并通过从平面文件加载来重用计算。
答案 2 :(得分：0)
这似乎是您正在使用的一个非常有趣的问题/应用程序。我很乐意在这样的事情上工作。 ：）
你的表面积非常大，这使得很难开始帮助。您的帖子中有几个解决方案参数不明显。例如，您计划保留运行分析表多长时间？还有很多其他问题需要提出。
您将需要结合严格的数据仓库和数据/表分区。根据您要保留和存档的数据量，您可能需要开始对表格进行反规范化和展平。
这是非常好的情况，直接联系Microsoft可以互惠互利。微软得到了向其他客户展示的好例子，并且您可以直接从供应商处获得帮助。
答案 3 :(得分：0)
我们最终将数据库拆分为多个数据库。因此，主数据库包含一个“数据库”表，该表引用一个或多个“运行”数据库，每个数据库包含不同的分析结果集。然后主“运行”表包含数据库ID，检索保存结果的代码包括所有查询的相关数据库前缀。
这种方法允许每个数据库的系统目录更加合理，它可以更好地分离核心/永久表和动态/运行表，还可以使备份和归档更易于管理。它还允许我们跨多个物理磁盘分割数据，尽管使用多个文件组也可以这样做。总的来说，考虑到我们目前的要求，它现在对我们来说运作良好，并且基于预期的增长，我们认为它也将适合我们。
我们还注意到SQL 2008倾向于比SQL 2000和SQL 2005更好地处理大型系统目录。 （当我发布这个问题时，我们没有升级到2008年。）