在SQL Server上创建和删除太多的表是否有缺点

我想知道以下使用数据库的方法是否存在固有缺陷。。。 我想创建一个带有web前端的报告系统，通过该系统，我可以查询数据库中的相关数据，并使用“SELECT INTO”将查询结果发送到新的数据表中。然后程序将从该表中进行查询，以显示报告的“页面”。这样做的好处是，如果有大量数据，可以将其作为页面一次呈现给用户一点。当用户请求报告的不同页面时，可以反复访问相同的数据表。当web会话结束时，可以删除这些表

我准备围绕跟踪表格和确保在需要时删除表格等问题进行编程

我有一个模糊的担忧，在很长一段时间内，数据库本身可能会有某种形式的维护问题，这是由于随着时间的推移创建和删除了太多的表。即使是一天一天，我们也会创建和删除1000个这样的表

有人认为有什么值得担心的吗

---

感谢您的建议/关注。

如果您谈论小桌子，每天1000张不应该是一个问题

我不知道sql server，但在Oracle中，您有临时表（和）的概念。插入此类表中的数据仅在当前会话中可用。当会话结束时，数据“disapear”。在这种情况下，你不需要放下任何东西。每个用户都在同一个表中插入数据，其他人看不到他的数据。优点：维护少。

---

您可以在SQLServer中检查是否有SimMerar。

< P>在开始执行解决方案之前，考虑使用或仅使用具有良好模型和适当索引表的SQLServer。SQL Server、IIS和操作系统都执行很难击败的缓存操作

---

令人担忧的是，您试图编写的代码将试图超越SQL Server和IIS。。。这是一个典型的过早优化示例。程序员花费了成千上万的时间来确保SQL Server和IIS尽可能快速高效，而且您的策略不太可能获得更好的性能

首先：+1至@Paul Sasik的答案

现在，回答你的问题（如果你仍然想继续你的方法）。 如果使用VARBINARY（MAX）列（）

如果删除一个包含VARBINAL（MAX）列的表 属性，则文件系统中存储的任何数据都不会被删除 删除

如果您决定采用您的方法，我将使用全局临时表。当没有更多的连接使用它们时，应该自动删除它们，但您仍然可以显式地删除它们。 在查询中，您可以检查它们是否存在，如果它们不存在（不再存在），则可以创建它们

---

这样，您就拥有了执行查询和一起管理临时表的大部分逻辑，这将使它更易于维护。此外，它们是为创建和删除而构建的，因此，可以很安全地认为，SQL Server不会因为创建和删除了大量它们而受到任何影响。

-1您怎么可能知道这是“过早优化”？对预先计算的结果表进行简单的查找很可能比使用

row\u number

从多表联接查询中获取第n页结果的方法更有效。在SQL Server中，分页查询没有得到很好的优化，即使使用了新的Denali语法改进，例如

OFFSET

，如果OP需要知道显示页面链接的前期结果总数，那么这可能会一举两得。@Martin:这是过早优化的原因，因为系统甚至没有并且OP已经在计划解决性能问题的方法。这就是早熟优化的定义。看这里：嗯，好吧，我看到你的观点被否决了@凯文：你考虑这件事的动机是什么？马丁：我们非常感谢你的重新考虑。马丁和保罗：我很感谢你们的想法和讨论。抱歉耽搁了。Martin询问我的动机——这个系统可能有非常大的报告，我希望将其作为XML读入内存，以便转换为HTML。我一次只想处理一页报告。因此，在我看来，一个好的解决方案似乎是使用数据库来存储所有结果并读取我需要的几行。原始查询可能非常复杂，因此我不希望SQL server必须为其他页面的后续用户请求重新运行该查询。

IF OBJECT_ID('mydb..##temp') IS NULL
-- create temp table and perform your query