Нужен совет про временные таблицы

Может быть ламерский вопрос, но все же:
Для сохранения большого объема (примерно 300000 записей) данных во временную табл. для дальнейшей обработки, какой конструкцией лучше воспользоваться?
declare @StoreTable table (a1 varchar(10) и т.д)
или
create table #StoreTable (a1 varchar(10) и т.д)
В чем преимущеста и недостатки каждого из этих способов?

Из BOL. Consider using table variables instead of temporary tables. Temporary tables are useful in cases when indexes need to be created explicitly on them, or when the table values need to be visible across multiple stored procedures or functions. In general, table variables contribute to more efficient query processing. For more information, see table.
посмотрите статьи create table, и table в BOL.
Используйте переменные вместо временных таблиц когда возможно :)

Я бы посоветовал для такого объема данных все-таки использовать временные таблицы (2 вариант). Имхо, при больших объемах данных переменные типа таблица уступают по производительности временным таблицам.

-=DiM@n=-

Я бы посоветовал для такого объема данных все-таки использовать временные таблицы (2 вариант). Имхо, при больших объемах данных переменные типа таблица уступают по производительности временным таблицам.

А подробнее можно :) ?

-=DiM@n=-

Я бы посоветовал для такого объема данных все-таки использовать временные таблицы (2 вариант). Имхо, при больших объемах данных переменные типа таблица уступают по производительности временным таблицам.

С чего бы это?
-------------------------------
Вы просто не умеете их готовить...

автор

А подробнее можно :) ?

автор

С чего бы это?

Ну вот хотя бы выдержка из BOL'а:

автор

Запросы, содержащие табличные переменные, не создают параллельные запросы планов выполнения. Производительность может снижаться при наличии очень больших табличных переменных или при наличии табличных переменных в сложных запросах. В подобных случаях целесообразно рассмотреть возможность использования временных таблиц.

Ну плюс еще на переменные-таблицы нельзя вешать индексы, нельзя использовать в инструкции типа (на 2000)
INSERT INTO @t
EXEC SomeProcedure
и т.п.

Вообщем, решать на самом деле автору, что ему выгоднее использовать, пусть попробует и то, и то для сравнения производительности.

автор

Запросы, содержащие табличные переменные, не создают параллельные запросы планов выполнения. Производительность может снижаться при наличии очень больших табличных переменных или при наличии табличных переменных в сложных запросах. В подобных случаях целесообразно рассмотреть возможность использования временных таблиц

если можно где именно это в BOL

pavel73

автор Запросы, содержащие табличные переменные, не создают параллельные запросы планов выполнения. Производительность может снижаться при наличии очень больших табличных переменных или при наличии табличных переменных в сложных запросах. В подобных случаях целесообразно рассмотреть возможность использования временных таблиц если можно где именно это в BOL

Ссылка в русском BOL'е:
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.ru/tsqlref9/html/1ef0b60e-a64c-4e97-847b-67930e3973ef.htm

В английском:
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/tsqlref9/html/1ef0b60e-a64c-4e97-847b-67930e3973ef.htm

Там прямо в ЗАМЕЧАНИЯХ (REMARKS) выделен этот кусок с пометкой важно.

Кстати, вот цитата из английского BOL'а:

BOL

Queries that contain table variables do not generate parallel query execution plans. Performance can be affected by the presence of very large table variables, or table variables in complex queries. In these situations, consider using temporary tables instead.

-=DiM@n=-

автор А подробнее можно :) ? автор С чего бы это? Ну вот хотя бы выдержка из BOL'а: автор Запросы, содержащие табличные переменные, не создают параллельные запросы планов выполнения. Производительность может снижаться при наличии очень больших табличных переменных или при наличии табличных переменных в сложных запросах. В подобных случаях целесообразно рассмотреть возможность использования временных таблиц. Ну плюс еще на переменные-таблицы нельзя вешать индексы, нельзя использовать в инструкции типа (на 2000) INSERT INTO @t EXEC SomeProcedure и т.п. Вообщем, решать на самом деле автору, что ему выгоднее использовать, пусть попробует и то, и то для сравнения производительности.

1) Ну прелести параллелизма - весчь на любителя.
2) Индексы вешаются без проблем, см. PRIMARI KEY и UNIQUE.
3) Ну тута придется признать: низзя. Но если подумать... а зачем оно?

да и на отсутствии журнала транзакций для @t выиграешь больше...