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

Volgende stap is testen op de volledige db (+ 1.000.000 producten) en uitzoeken hoe ik de index kan updaten zonder de hem volledig te herbouwen. Wordt vervolgd…

Meer details http://ajaxian.com/archives/google-analytics-unblocks-the-web-w-async-support

http://stackoverflow.com/questions/480946/asp-net-dopostback-not-rendered-sometime

Op mijn nieuwe desktop pc staan zowel het OS als alle MySql files op een Solid State Disk. Om de test een beetje zinnig te houden had MySql op beide machines evenveel Ram te beschikking. Mijn nieuwe pc was na 5 uur klaar! Dat is dus maar even 10 keer sneller! Een dikke aanrader dus.

OCZ Vertex Turbo SSD Retail Package

De kogel is door de kerk. Ik heb na 5 jaar nog maar eens een nieuwe pc gekocht. Het zou een goed snel machine moeten worden. Intel i7 920, 6GN DDR3 Ram EN het OS op een 120GB solid state drive. (Vertex Turbo Series 120GB SATA II Solid State Disk, zie image). Volgende week zou ik hem moeten hebben, ik ben benieuwd…

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�

Op een grotere site staat de crawl rate momenteel 2.5 pages/sec. Per dag geeft dit pieken boven de 200.000 pagina’s. So, Handle with care…