I see. When you say 'a bit more clarity', does that mean 'a bit more uniqueness'? Presumably as a way to avoid collisions? That may reduce the risk, if everyone sticks to the plan, but there are no guarantees. With a table variable, the issue does not arise.

This is true (although table variables can also have a primary key and unique non-clustered indexes, albeit without statistical information). On the other hand, the ability to create extra indexes and statistics can be a double-edged sword. Statistics may need to be maintained, changes in table cardinality and schema may force unnecessary recompilations, and so on.

Performing DDL after table creation also prevents SQL Server using some of the caching optimizations for temporary structures present in 2005 onward. Specifically, SQL Server is often able to cache a single data page and an IAM page with the query plan, avoiding the overhead of creation and allocation each time the procedure is executed. Performing DDL after creation defeats this optimization. One cannot perform DDL on a table variable after creation, so again, the issue does not arise.

Both have their strengths and weaknesses, and the more rounded approach is to use each where it is suited. Table variables have many advantages aside from passing TVPs around:

1. Named constraints are problematic with #temp tables (another name-collision problem). You cannot name a constraint on a table variable, so again the problem is avoided in all cases.

2. Table variables can use user-defined data types and XML schemas defined in the context database. Temporary tables cannot use either, unless they happen to have identical definitions in tempdb, which is inconvenient, and tough to maintain robustly.

3. Temporary tables inherit the collation of tempdb, whereas table variables use the context database. It is not all that uncommon for user databases to differ from tempdb in collation, and I do not enjoy resolving collation conflicts.

4. Data stored in a table variable in the context of a user transaction is not rolled back with the transaction. This can be invaluable, e.g. where we need to log information after a roll back.

5. Table variables are the only available choice in function definitions.

So, I am absolutely not saying that table variables should replace temporary tables every time. I personally prefer to start with a table variable design, and look for reasons that would justify changing to use a temporary table.

In practice, I often find that the presence of a temporary object (of sufficient size or complexity to make a table variable a poor choice) an indicator that I am doing something dumb. Specifically, manipulating large amounts of data, creating indexes, relying on statistics to produce a non-trivial plan...all this is work that is performed again and again, on every execution. Often, it indicates that the present overall database design is lacking.

Paul