Best options to use in Temp Table

Question

Hello,
I was just trying to figure out the best options we can choose with when we come across a scenario where we need to use a  Temp Table/Table Variable/Create
a Temp Table on the fly.
However, I could not see any big difference in using those options. As per my understanding using a table variable is more convenient if the query logic is
small and the result set also will be comparatively small.Creating a temp table is also an easy option but it takes much time and we can not create any indexes on it. I am working on a query optimization task where in plenty of temp tables are used
and the query takes more than five minutes to execute. We have created few indexes and all in few tables and reduced the query execution time up to 2 mnts.Can anyone give me more suggestions on it. I have gone through various articles about it and came to
know that there is no one solution for this and I am aware of the basic criteria like  use Set No count on, Order the table in which the indexes are created, Do not use Select * instead use only columns which are really required, Create Indexes
and all. Other than these I am stuck with the usage of temp tables. There are some limitations where I can convert all the Temp table logic to CTE (I am not saying its not possible, I really dont have time to spend for the conversion). Any suggestions are
welcome.
Actual Query
select Code,dbo.GetTranslatedText(Name,'en-US')
as Name from ProductionResponse.ProductionResponse
00.00.02
5225 rows
With Table Variable
DECLARE  @General
TABLE(Code
NVarchar(Max),Name
NVarchar(Max)
INSERT
INTO @General
select Code,dbo.GetTranslatedText(Name,'en-US')
AS Name  from ProductionResponse.ProductionResponse
select
* from @General
00.00.03
5225 rows
With an Identity Column
DECLARE  @General
TABLE(Id
INT IDENTITY(1,1)
,Code NVarchar(Max),Name
NVarchar(Max)
INSERT
INTO @General
select Code,dbo.GetTranslatedText(Name,'en-US')
AS Number  from ProductionResponse.ProductionResponse
select
* from @General
00.00.04
5225 rows
With Temp Table:
CREATE
TABLE #General (Id
INT IDENTITY(1,1)
PRIMARY KEY,Code
NVarchar(Max),Name
NVarchar(Max)
INSERT
INTO #General
select Code,dbo.GetTranslatedText(Name,'en-US')
as Name from ProductionResponse.ProductionResponse
select
* from #General
DROP
TABLE #General
00.00.04
5225 rows
With Temp Table on the Fly
SELECT G.Code,G.Name
INTO #General  
FROM
select Code,dbo.GetTranslatedText(Name,'en-US')
as Name from ProductionResponse.ProductionResponse
)G
select
* from #General
00.00.04
5225 rows

Answer 1

>> I was just trying to figure out the best options we can choose with when we come across a scenario where we need to use a Temp Table/Table Variable/Create a Temp Table on the fly. <<
Actually, we want to avoid all of those things in a declarative/functional language. The goal is to write the solution in a single statement. What you are doing is mimicking a scratch tape in a 1950's tape file system. 
Another non-declarative technique is to use UDFs, to mimic 1950's procedural code or OO style methods. Your sample code is full of COBOL-isms! In RDBMS we follow ISO-11179 rules, so we have “<something in particular>_code” rather than just “code” like
a field within a COBOL record. The hierarchical record structure provides context, but in RDBMS, data elements are global.  Or better, they are universal names. 
>> I am aware of the basic criteria like use SET NO COUNT ON, Order the table in which the indexes are created, Do not use SELECT * instead use only columns which are really required, CREATE INDEXes and all.<<
All good, but you missed others. Never use the same name for a data element (scalars) and a table (sets). Think about what things like “ProductionResponse.production_response” means. A set with one element is a bit weird, but that is what you said. Also, what
is this response? A code? A count? It lacks what we call an attribute property. 
This was one of the flaws we inherited when ANSI standardized SQL and we should have fixed it. Oh well, too late now. 
Never use NVARCHAR(MAX). Why do you need to put all of the Soto Zen sutras in Chinese Unicode? When you use over-sized data elements, you eventually get garbage data. 
>> Other than these I am stuck with the usage of temp tables. There are some limitations where I can convert all the Temp table logic to CTE (I am not saying its not possible, I really do not have time to spend for the conversion). Any suggestions are
welcome.<<
Yes! This is how we do declarative/functional programming! Make the effort, so the optimizer can work, so you can use parallelism and so you can port your code out of T-SQL dialect. 
--CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking
in Sets / Trees and Hierarchies in SQL