You may create constraints and indexes on temporary tables. I think you would benefit by having a regular table; that way you could depend on constraints and indexes and possibly updated statistics always being there. There are global and local temp tables depending on a declaration like #tbl or ##tbl and the local ones are cleaned up when a connection is closed. I find that there is overhead in using global objects accessible outside of a connection. Temp tables cause contention in sysobjects which might be a problem if you are often creating and dropping them.

Table variables within a stored procedure perform very well if there are less than thousands of rows and they benefit from constraints.

You may need to play around with your unique situation to find out empirically what works best.