Site sponsored by: Idera Try Idera’s new SQL admin toolset
SQL Server Performance

  • Home
  • Articles
  • Forums
  • Tips
  • Quiz
  • FAQ's
  • Blogs
  • Software
  • Books
  • About Us
RSS Feeds
Sign in | Join


FAQ Topics

All FAQ's
General DBA
General Developer
DBA Performance Tuning
Developer Performance Tuning
Clustering
Error Messages

Write for Us

Share you SQL Server knowledge with others and raise your profile in the community More...
Latest Articles

Policy Based Management in SQL Server 2008
Inside SQL Server Cluster Setup and Troubleshooting Techniques - Part I ...
Configure and Manage Policy Based Management in SQL Server 2008 ...
Using Column Sets with Sparse Columns

More     
 
Latest FAQ's

Cannot Start SQL Server Service
Users are able to connect to report manager but not able ...
Errors when SQL Server Snapshot Replication is Running
How to Display Server Name or IP Address in a Reporting ...

More     
   
Latest Software Reviews

Spotlight on ApexSQL Doc 2008
ApexSQL Enforce
Embarcadero Change Manager
SQL Server DBA Dashboard

More     

My application makes heavy use of temp tables. Should I be creating temp tables as needed, or should I be using a permanent table over and over instead?



Assuming everything is the same, both tables will produce very similar access speeds. If your application makes heavy use of temp tables, you might consider using a permanent table for these reasons: 

  • A regular table already exists. A temp table has to be created, which takes time and overhead. For example, if you need to create a temp table 500 times a day, obviously a permanent table would be more efficient.
  • A regular table can have preexisting indexes, while a temp table does not, unless you add them, which takes more overhead. Yes, records may take a little longer to INSERT if a preexisting index exists, but overall, the overhead is less than having to INSERT your data into a temp table, and then add an index.
  • A temp table, when used, has to be managed in the tempdb database, which is additional overhead as it is created, used, and deleted. A regular table already exists, and doesn't take any extra effort to manage.
  • A permanent table acts more like a global temp table than a local temp table. This may or may not be to your advantage. But even if you want the advantages of a local temp table, a permanent table will still work if you include the necessary column to differentiate the rows of different users, and the appropriate code.

Each of these potential benefits of permanent tables over temp tables is small, but in some situations, can add up to big performance savings. The only way to know for sure in your situation is to try both options.








Home | Peformance Articles | Audit Articles | Business Intelligence Articles | Clustering Articles | Developer Articles | Reporting Services Articles | DBA Articles | ASP.NET / ADO.NET Articles | DBA FAQ's | Developer Peformance FAQ's | DBA Peformance FAQ's | Developer FAQ's | Clustering FAQ's | Error Messages | Audit Tool Reviews | Backup Tool Reviews | Coding Tool Reviews | Compare Tool Reviews | Documentation Tool Reviews | Design Tool Reviews | Monitoring Tool Reviews | Log Tool Reviews | Reporting Tool Reviews | Clustering Tool Reviews | Security Tool Reviews | Change Management Tool Reviews | Remote Access Tool Reviews | Book Reviews | Security Tool Reviews | QDPMA Performance Tuning | ADO.NET / ASP.NET | Administration | Analysis/OLAP Services | Application Development | Configuration | Components | ETL | Hardware | High Availability | Hints | Index | Misc | Operating Systems | Performance Tuning | Replication | T-SQL | Views


              © 1999-2008 by T10 Media. All rights reserved