我想知道以下使用数据库的方式是否存在固有缺陷... 我想创建一个带有 Web 前端的报告系统，从而查询数据库中的相关数据，并使用“SELECT INTO”将查询结果发送到新数据表。然后程序将从该表中进行查询以显示报告的“页面”。这样做的好处是，如果有很多数据，可以一次将其作为页面呈现给用户一点。当用户请求报告的不同页面时，可以反复访问同一个数据表。当网络会话结束时，可以删除表。
我准备围绕诸如跟踪表和确保在需要时删除它们等问题进行编程。
我有一个模糊的担忧，在很长一段时间内，由于随着时间的推移创建和删除了如此多的表，数据库本身可能存在某种形式的维护问题。即使是一天一天，假设可能有 1000 个这样的表被创建和删除。
有人觉得有什么值得担心的地方吗？
感谢您的任何建议/疑虑。
【问题讨论】：
标签： sql sql-server maintenance
在您开始实施您的解决方案之前，请考虑使用SSAS 或仅使用具有良好模型和正确索引表的 SQL Server。 SQL Server、IIS 和操作系统都执行难以击败的缓存操作。
令人担忧的原因是，您正在尝试编写性能优于 SQL Server 和 IIS 的代码...这是过早优化的经典示例。为了确保 SQL Server 和 IIS 尽可能快速和高效，程序员已经花费了成千上万的时间，而且您的策略不太可能获得更好的性能。
【讨论】：
row_number 从多表连接查询中获取第 N 页结果的方法。即使使用了新的 Denali 语法改进（例如OFFSET），SQL Server 中的分页查询也没有得到很好的优化，如果 OP 需要预先知道结果总数以显示页面链接，那么这可能会一石二鸟。
首先：+1 @Paul Sasik 的回答。
现在，回答您的问题（如果您仍想采用您的方法）。 如果您使用 VARBINARY(MAX) 列 (from the MSDN)，可能会引起关注
如果删除包含 VARBINARY(MAX) 列的表 FILESTREAM 属性，文件系统中存储的任何数据都不会 删除。
如果您决定采用您的方法，我会使用全局临时表。当没有更多的连接使用它们时，它们应该会自动被 DROPped，但您仍然可以显式地 DROP 它们。 在您的查询中，您可以检查它们是否存在，如果它们不存在则创建它们（不再存在）。
IF OBJECT_ID('mydb..##temp') IS NULL
-- create temp table and perform your query
这样，您就拥有了执行查询和管理临时表的大部分逻辑，这应该使其更易于维护。此外，它们是为创建和删除而构建的，因此可以肯定地认为 SQL Server 不会因创建和删除大量它们而受到任何影响。
【讨论】：
如果您谈论小桌子，每天 1000 个应该不是问题。
我不知道 sql-server，但是在 Oracle 中你有临时表的概念（small article 和 another）。插入到此类表中的数据仅在当前会话中可用。当会话结束时，数据“消失”。在这种情况下，您不需要丢弃任何东西。每个用户都在同一个表中插入，他的数据对其他人是不可见的。优点：维护少。 你可以检查一下你在 sql-server 中是否有类似的东西。
【讨论】：