Обычная таблица или глобальная временная таблица?

Я и еще один разработчик обсуждаем, какой тип таблицы больше подходит для нашей задачи. По сути, это будет кеш, который мы собираемся усечь в конце дня. Лично я не вижу причин использовать для этого что-либо, кроме обычной таблицы, но он хочет использовать глобальную временную таблицу.

Есть ли преимущества у одного или другого?


sql-server temp-tables
person Jeremy Cantrell    schedule 20.01.2011    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Используйте обычную таблицу в tempdb, если это просто временные данные, которые вы можете позволить себе потерять при перезапуске службы, или базу данных пользователя, если данные не являются такими временными.

tempdb немного более эффективен с точки зрения требований к ведению журнала.

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

Изменить: после редактирования @ cyberkiwi. BOL определенно явно говорит

Глобальные временные таблицы видны любому пользователю и любому соединению после их создания и удаляются, когда все пользователи, которые ссылаются на таблицу, отключаются от экземпляра SQL Server.

Однако в моем тесте я не смог добиться такого поведения.

Подключение 1

CREATE TABLE ##T (i int)
INSERT INTO ##T values (1)
SET CONTEXT_INFO 0x01

Подключение 2

INSERT INTO ##T VALUES(4)
WAITFOR DELAY '00:01'
INSERT INTO ##T VALUES(5)

Подключение 3

SELECT OBJECT_ID('tempdb..##T') 
declare @killspid varchar(10) = (select 'kill ' +  cast(spid as varchar(5)) from sysprocesses where context_info=0x01)
exec (@killspid)
SELECT OBJECT_ID('tempdb..##T') /*NULL - But 2 is still 
                                 running let alone disconnected!*/
person Martin Smith    schedule 20.01.2011
comment
Не могли бы вы пояснить, насколько эффективнее tempdb? - person Jeremy Cantrell; 20.01.2011
comment
@Jeremy - Для начала он будет в simple модели восстановления, тогда как другая ваша БД может и не быть. Но даже без этого ему нужно вести меньше журналов, чем это было бы в пользовательской базе данных с простой моделью восстановления, поскольку ему не нужно регистрировать материал, который позволил бы ему повторить транзакции в случае сбоя сервера. (tempdb просто воссоздается при перезапуске сервера, поэтому не требуется возможности отката транзакций, которые были зафиксированы и, таким образом, записаны в журнал транзакций, но еще не записаны в файлы данных на диске) - person Martin Smith; 20.01.2011

arrow_upward
2
arrow_downward

Таблица глобальной температуры

  • -ve: как только соединение that created таблица выходит за пределы области видимости, таблица забирается вместе с ней. Это вредно, если вы используете пул соединений, который может постоянно менять соединения и, возможно, сбрасывать их.
  • -ve: вам нужно продолжать проверять, существует ли уже таблица (после перезапуска), и создавать ее, если нет
  • + ve: Простая регистрация в базе данных tempdb снижает количество операций ввода-вывода и ЦП

Нормальный стол

  • + ve: Обычное ведение журнала хранит ваш кеш вместе с вашей основной базой данных. Если ваш "кеш" поддерживается, но по-прежнему критически важен, это поддерживает его согласованность с базой данных.
  • -ve: следовать сверху Больше протоколирования
  • + ve: стол всегда рядом и для всех подключений

Если кеш представляет собой что-то вроде краткого обзора для бизнес-/ критических данных, даже если он сброшен / усечен в конце дня, я бы предпочел оставить его как обычную таблицу в самой БД.

person RichardTheKiwi    schedule 20.01.2011
comment
Я получил те же результаты, что и вы, при тестировании срока службы ## временных таблиц. Не уверен, что именно означает BOL. Этот ответ заставляет меня думать, что, возможно, это может иметь значение, если на них будут ссылаться хранимые процедуры, но я не тестировал это (у меня есть другие дела!) - person Martin Smith; 04.02.2011