Локальные и глобальные временные таблицы — когда что использовать?

У меня есть отчет, который при выполнении подключается к базе данных с именем пользователя my_report_user. Конечных пользователей отчета может быть много. И при каждом выполнении будет производиться новое подключение к БД с my_report_user (пула соединений нет)

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

Должен ли я использовать local временных таблиц (#) или global временных таблиц (##)?

Кто-нибудь пробовал такие вещи, и если да, пожалуйста, дайте мне знать, о чем мне следует заботиться? (Почти одновременный запуск отчетов и т. д.)

РЕДАКТИРОВАТЬ: я использую Sql-Server 2005


sql sql-server reporting sql-server-2005 tempdb
person peakit    schedule 20.10.2009    source источник
comment
Какая версия SQL Server? Если 2005+, CTE (и, возможно, рекурсивные CTE) являются еще одним вариантом. Не зная больше о том, что вам нужно с ними делать, я рекомендую использовать локальные, а не глобальные временные таблицы...   -  person OMG Ponies    schedule 20.10.2009
comment
Делаем наихудшее предположение: глобальная временная таблица не удаляется, потому что к ней все еще существуют соединения, в какой момент данные в этой таблице становятся недействительными? т. е. что определяет, когда данные обязательно должны обновляться, чтобы избежать появления неправильных данных в отчетах?   -  person Chris J    schedule 20.10.2009
comment
его sql-сервер 2005. Вы уверены, что локальные временные таблицы позволяют мне повторно использовать их. Я думал, что локальные временные таблицы не позволят повторно использовать несколько отчетов. Что вы скажете теперь, зная версию?   -  person peakit    schedule 20.10.2009
comment
@Chris J, очень хороший вопрос. Данные в значительной степени статичны и должны обновляться раз в месяц или около того. Но, пожалуйста, объясните оба сценария.   -  person peakit    schedule 20.10.2009

Ответы (3)


arrow_upward
4
arrow_downward

Ни

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

Временные таблицы, bot #local и ##shared имеют время жизни, контролируемое соединением(ями). Если ваше приложение отключается, временная таблица удаляется, и это не работает с тем, что вы описываете.

Настоящая трудная проблема будет состоять в том, чтобы заполнить эти кешированные наборы результатов при параллельных запусках, не смешивая вещи (в конечном итоге наборы результатов будут содержать повторяющиеся элементы из параллельных запусков отчетов, которые оба считают «первым» запуском).

В качестве примечания службы отчетов SQL Server уже делают это «из коробки». Вы можете кэшировать и делиться наборами данных, вы можете кэшировать и делиться отчетами, это уже работает и было протестировано для вас.

person Remus Rusanu    schedule 20.10.2009
comment
Настоящей трудной проблемой будет заполнение этих кэшированных наборов результатов при одновременном выполнении, не смешивая вещи. Я также беспокоюсь об этом. Спасибо за помощь, кстати. - person peakit; 20.10.2009
comment
Вы можете использовать блокировки приложений. Используйте ресурс, который идентифицирует отчет, который вы просматриваете, например. отчет о продажах за северо-западный финансовый октябрь 2009 г. или отчет с идентификатором 42. 1. sp_getapplock 'общий', 'сеанс'. 2. проверьте набор данных, если он есть, используйте его для отчета, затем снимите блокировку приложения и выйдите. 3. если нет, отпустите приложение loc, получите его обратно X sp_getapplock 'exclusive', 'session'. 4. Проверьте еще раз, существует ли отчет, если нет, создайте его и используйте, снимите блокировку и выйдите. 5. Если отчет существует после получения блокировки X, снимите блокировку x и вернитесь к шагу 1. - person Remus Rusanu; 20.10.2009
comment
Я ценю ваши знания. Но все же есть шансы, что набор результатов будет очищен движком (когда нет активных подключений к этой временной таблице ##). Это побеждает мою цель, подобную кэшированию. Что сказать? Хотя какой бы механизм блокировки вы ни предоставили, он может решить проблему параллелизма... - person peakit; 20.10.2009
comment
Вот почему я говорю, не используйте ##таблицы любого вида. - person Remus Rusanu; 20.10.2009

arrow_upward
3
arrow_downward

Я считаю, что таблицы #temp могут быть полезны в определенных сценариях, но не в качестве лучшей практики. Мне еще предстоит найти правильное применение глобальным таблицам ##temp ни в моей собственной работе, ни в работе кого-либо еще, кто писал о них. Единственный случай, о котором я могу думать, — это BCP или другой внешний процесс, которому необходимо создать временное хранилище данных, а затем получить его на каком-то последующем этапе. В этом случае я бы предпочел использовать постоянную таблицу с каким-то ключом и фоновым процессом для очистки.

person Aaron Bertrand    schedule 20.10.2009

arrow_upward
0
arrow_downward

Похоже, вы сейчас переходите в режим OLTP. Чтение о хранилищах баз данных определенно поможет вам.

person Raj More    schedule 20.10.2009