In the example you have provided, it will be much faster to use the real table. I don't see any valid reasons for you to contemplate creating a temporary table when all you are doing is making an exact copy of the table and it's data.
I don't see any valid reasons for you to contemplate creating a temporary table when all you are doing is making an exact copy of the table and it's data."
In the shop I work in it can be useful on the production server. I can't create tables there but they are not always linked so I can get to production from test. It wouldn't be a straight copy though so I agree with what you are saying. It would be a subset used further down. I think the OP used that as an example to illustrate the question.
I wouild also suggest that if you are filtering the data, a derived table can be faster than either a temp table ora table vaiable. But as with all performance questions, the real anaswer depends greatly on your own database design and the actual data and the frequency the data is being accessed. I would try all three and see which works best in your own particular situation.
"NOTHING is more important in a database than integrity." ESquared
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.