这个问题与另一个问题有关：
拥有多个文件组会帮助加快数据库速度吗？

我们正在开发的软件是使用MS SQL Server 2005存储关系数据的分析工具。初始分析可能很慢(因为我们正在处理数百万或者数十亿行的数据)，但是对快速调用以前的分析有性能要求，因此我们"保存"每个分析的结果。

我们当前的方法是将分析结果保存在一系列"特定于运行"的表中，并且分析非常复杂，最终每个分析最多可能有100个表。通常，这些表每次分析会占用数百MB(与源数据的数百GB或者有时为数TB的存储空间相比，这是很小的)。但是总的来说，磁盘空间对我们来说不是问题。每组表都特定于一个分析，并且在许多情况下，相对于引用源数据，这为我们提供了巨大的性能改进。

一旦我们积累了足够的保存的分析结果，该方法便开始崩溃-在我们添加更强大的存档/清除功能之前，我们的测试数据库已攀升至几百万张表。但是，即使在生产中，拥有超过100,000张桌子也不是一件容易的事。微软对sysobjects的大小(〜20亿)设置了相当大的理论限制，但是一旦我们的数据库增长到100,000左右，简单的查询(例如CREATE TABLE和DROP TABLE)就会大大降低。

我们有一定的空间来辩论我们的方法，但是如果没有更多上下文，我可能很难做到这一点，因此我想更笼统地问这个问题：如果我们被迫创建这么多的表，那么管理的最佳方法是什么？他们？多个文件组？多个架构/所有者？多个数据库？

另一个注意事项："让硬件简单地解决问题"(即增加RAM，CPU能力，磁盘速度)的想法我并不感到惊讶。但是我们也不会排除它，特别是(例如)如果有人可以明确地告诉我们添加RAM或者使用多个文件组对管理大型系统目录有什么影响。

解决方案

这似乎是我们正在处理的一个非常有趣的问题/应用程序。我很想从事这样的工作。 :)

问题表面积很大，因此很难开始提供帮助。有几个解决方案参数在帖子中并不明显。例如，我们打算将运行分析表保留多长时间？还有很多其他问题需要提出。

我们将需要严肃的数据仓库和数据/表分区的结合。根据要保留和归档的数据量，我们可能需要开始对表格进行非规范化和展平。

如果直接联系Microsoft可以是互惠互利的，那将是一个很好的情况。 Microsoft获得了向其他客户展示的好案例，我们可以直接从供应商那里获得帮助。

桌子都是不同的结构吗？如果它们是相同的结构，那么我们可能会得到一个分区表。

如果它们是不同的结构，而只是相同维列集的子集，则仍可以将它们存储在同一表的分区中，而在不适用列中则为空。

如果这是分析性的(也许是衍生价格计算？)，则可以将计算运行的结果转储到平面文件中，并通过从平面文件中加载来重复使用计算。

在不首先看到整个系统的情况下，我的第一个建议是将历史运行保存在带有RunID作为键的一部分的组合表中，维模型在这里也可能是相关的。可以对该表进行分区以进行改进，这也将使我们可以将该表扩展到其他文件组。

另一种可能是，将每个运行放入其自己的数据库中，然后分离它们，仅根据需要添加它们(并以只读形式)

CREATE TABLE和DROP TABLE可能表现不佳，因为master或者model数据库没有针对这种行为进行优化。

我还建议我们与Microsoft讨论我们对数据库设计的选择。