Нормальная таблица или глобальная временная таблица? - PullRequest
Новая
       3

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

3 голосов
/ 20 января 2011

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

Есть ли какие-либо преимущества для одной или другой?

Ответы [ 2 ]

5 голосов
/ 20 января 2011

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

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

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

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

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

В моем тесте я также не смог получить такое поведение.

Соединение 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!*/
2 голосов
/ 20 января 2011

Глобальная временная таблица

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

Обычный стол

  • + ve: Нормальное ведение журнала хранит ваш кеш с вашей основной БД. Если ваш «кеш» поддерживается, но по-прежнему критически важен, он поддерживает его вместе с db
  • -ve: следовать сверху Больше журналов
  • + ve: Стол всегда рядом, и для всех соединений

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

...