我们每周从客户端导入大量数据，并将其附加到SQL Server数据库的内部表中。我们有一位经理认为，为每周我们从这些数据运行的某些报告创建（并希望删除）临时表更容易，也更方便。
（我们做这样的事情 - 方式过于简单：从这个主要表中选择一美元或更多且超过21美元的客户的记录，然后我们发送账单;然后为欠少于1美元的客户选择记录并且在21以下，然后在我们发送账单之前将后面的记录与某些连接上的其他表匹配。当前进程将这些选定记录集中的每一个转储到该周的单独临时表中，并且在发送账单之后表应该被删除。做坏事的方法，我知道......你不必告诉我那个！）
我的观点是，一切都应该进入一个表，使用一个标记哪个星期数据的列，然后将数据保存在那里，并使用该列的值作为标准运行查询。或者，在将这些记录用于本周的报告后，只删除这些记录。
NOW ...
我的全部要点是：
是否有大量额外（不必要的）表会降低数据库性能？
或者，当您必须在SQL Server Management Studio对象资源管理器窗口中滚动数百个旧表时，它只是浪费磁盘空间并且看起来像一团糟，但它并没有真正损害性能？
我正在尝试为这位经理提供理由，说明为什么我们应该废弃制作所有这些临时表的例程并将其重写为从一个主表中选择所有内容。重做事情可能需要做一些工作，但一旦完成它应该更有效，更容易维护等。
答案 0 :(得分：1)
是否有大量额外（不必要的）表会降低数据库性能？
没有。除非我们讨论数以万计的表格，否则我从未在过多的表格中看到过性能问题。
或者它只是浪费磁盘空间，当你必须在SQL Server Management Studio对象资源管理器窗口中滚动数百个旧表时看起来像一团糟，但它并没有真正损害性能？< / em>的
这是一个偏好的事情。它确实看起来像一团糟，但并没有真正伤害表演。
现在的问题是：清洁所有这些值得花时间的努力是否节省了生产力和加工这种意大利面的工作？
答案 1 :(得分：1)
我会说你使用视图而不是外部表。这样，如果需要修改或更正“源数据”，您的报告就会反映出来。
在磁盘空间上，每个表都写在自己的文件中，并带有自己的索引文件。表格内容太大而无法容纳（例如nvarchar（max））将存储在自己的文件中。
Luckely，数据库管理器（sql server）为你管理文件，所以不用担心。
对于“大数据”评估，拥有尽可能纯粹的输入数据至关重要。因此，在创建日期时将其标记为允许您轻松选择在特定时间段内创建的数据。
另一种选择是创建一个存储过程来填充临时数据库或内存数据库并返回该数据库，这样您就可以对返回的有限集执行选择查询。 Sql server仍会以某些数据集大小生成文件，因为它更有效，但是在完成后它会自行清理。
我永远不会使用临时表中的每周数据集。 我真正考虑使用非常大的数据集的唯一方法是制作年度单独的表，因此索引可以相当快速地迭代，如果需要多年语句，联合相对便宜。
那么，回答你的问题： 多个表不会妨碍性能。但是，它确实提高了开发人员的灵活性和数据库维护，增加了人员成本。还有更好的未来替代品。