benieuwd hoeveel hij hier gaat kosten…

Behave just like normal tables, but are created in the TempDB database. They persist until dropped, or until the connection that created them disappears. They are visible in the procedure that created them and any procedures that that proc calls.

Just like normal tables, they can have primary keys, constraints and indexes, and column statistics are kept for the table.

Temp tables, while they have space assigned to them in the tempDB database, will generally be accessed only from memory, unless the server is under memory pressure, or the amount of data in the table is large.

Table Variables

These tables behave very much like other variables in their scoping rules. They are created when they are declared and are dropped when they go out of scope. They cannot be explicitly dropped.

Like with temp tables, table variables reside in TempDB. they have entries in the system tables in tempDB, just like temp tables, and they follow the same behaviour regarding whether they are in memory or on disk.

Table variables can have a primary key, but indexes cannot be created on them, neither are statistics maintained on the columns. This makes table variables less optimal for large numbers of rows, as the optimiser has no way of knowing the number of rows in the table variable.

CTE

In my experience, CTEs are more like temporary views than anything else. When you look at the execution plan, you’ll see that they are inlined into the query, not materialised and stored. I find, with the exception of recursion, they’re more to make queries simpler to write than faster to run.

(Bron http://www.sqlservercentral.com/Forums/Topic415829-338-1.aspx)

meer nuttige artikels

http://www.sql-server-performance.com/articles/per/temp_tables_vs_variables_p1.aspx

http://sqllearnings.blogspot.com/2009/04/issues-with-abusing-table-variables.html

http://blogs.msdn.com/craigfr/archive/2007/10/18/ctes-common-table-expressions.aspx

SELECT db_name(ps.database_id), object_name(ps.OBJECT_ID),
 b.name, ps.avg_fragmentation_in_percent, ps.page_count
 FROM sys.dm_db_index_physical_stats (db_id(‘myDatabase’), NULL, NULL, NULL, ‘LIMITED’) AS ps
 INNER JOIN sys.indexes AS b ON ps.OBJECT_ID = b.OBJECT_ID
 AND ps.index_id = b.index_id
 WHERE ps.database_id = DB_ID() and avg_fragmentation_in_percent > 50 and b.name <> ‘NULL’
 ORDER by ps.avg_fragmentation_in_percent desc

Het script geeft een lijst terug van alle indexen die meer dan 50% gefragmenteerd zijn. Wanneer er veel inserts in je database tabellen gebeuren is het goog practice om de fillfactor die databases aan te passen en om regematig de indexen bij te werken met ALTER INDEX .. REORGANIZE�