SQL Server/Oracle: частные временные таблицы. Sql временные таблицы

Transact-sql – Табличные функции и временные таблицы. | Info-Comp.ru

Сегодня поговорим об очень полезном функционале в Transact-sql это табличные функции. Так как у нас сайт для начинающих программистов, а такие программисты по началу боятся использовать табличные функции или просто не знают, зачем они нужны. Поэтому я решил рассказать про основы создания таких функций. А также рассказать про использование временных таблиц в процедурах. Примеры будем использовать на сервере Ms Sql 2008.

Начнем с табличных функций

Раньше мы уже знакомились с функциями, которые возвращают таблицу, правда, на языке PL/pgSQL для сервера PostgreSQL (статья - Пишем функцию на SQL которая возвращает таблицу). Теперь пришло время поговорить о такой реализации на Transact-sql.

Сразу скажу, что такие функции здесь пишутся намного легче, чем в PostgreSQL (хотя для кого как:)).

Вспомним, а для чего нам вообще нужны такие функции. Самый простой ответ на этот вопрос это то, что в таких функциях можно программировать (объявлять переменные, выполнять какие-то расчета) и передавать параметры внутрь этой функции как в обычных скалярных функциях, а результат получать в виде таблицы. И это хорошо ведь в представлениях (вьюхах) этого делать нельзя, а процедура ничего не возвращает.

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

Примечание! Данный пример можно реализовать и с помощью представления. Но мы пока только учимся писать такие функции.

--название нашей функции CREATE FUNCTION [dbo].[fun_test_tabl] ( --входящие параметры и их тип @id int ) --возвращающее значение, т.е. таблица RETURNS TABLE AS --сразу возвращаем результат RETURN ( --сам запрос SELECT * from table where id = @id ) GO

Итого, мы создаем функцию, в которую будем передавать id и по этому id из таблицы table получим наши данные.

Получить данные из этой функции можно вот так:

select * from dbo.fun_test_tabl (1)

Как видите все проще простого. Теперь давайте создадим функцию уже с использованием программирования в ней.

--название нашей функции CREATE FUNCTION [dbo].[fun_test_tabl_new] ( --входящие параметры @number int ) -- возвращающее значение, т.е. таблица с перечислением полей и их типов RETURNS @tabl TABLE (id int, number int, summa money) AS BEGIN --объявляем переменные declare @var money --выполняем какие-то действия на Transact-sql if @number >=0 begin set @var=1000 end else set @var=0 --вставляем данные в возвращающий результат INSERT @tabl SELECT id, number, summa from tabl where summa > @var --возвращаем результат RETURN End

Здесь мы уже программируем и можем выполнять любые действия как в обычных функциях и процедурах, при этом получая результат в виде таблицы. Т.е. здесь мы передаем какой-то параметр внутрь нашей функции (их может быть несколько!), допустим у нас, он может быть как положительный, так и отрицательный. Внутри функции мы уже смотрим, что за параметр к нам пришел и на основе этого уже формируем условие для запроса. Как вы понимаете это тоже простой пример, но можно писать очень и очень сложные алгоритмы как в процедурах, поэтому, и созданы эти табличные функции.

Теперь можем пробовать получать результат, например

select * from dbo.fun_test_tabl_new (1)

или

select * from dbo.fun_test_tabl_new (-1)

Временные таблицы

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

Например, в процедуре Вам необходимо выполнять много расчетов и запоминать их результат, а создавать дополнительные представления, табличные функции или вообще таблицы, которые потом нужно удалять, так как они вам после выполнения процедуры будут не нужны, Вам просто не охота, да и это не очень удобно. Поэтому в MsSql существует такая возможность как «Временные таблицы». Давайте научимся их создавать. А создавать и использовать их очень просто, например, в коде своей процедуры, Вы хотите сохранить результат в таблицу, для этого просто создаете эту таблицу вот так (перед названием таблицы ставится знак решетки).

CREATE TABLE #tmp(column1 int, column2 INT, column3 MONEY) INSERT INTO #tmp(column1, column2, column3) select data1, data2, data3 from table --Затем по коду ниже Вы ее можете использовать, а в конце процедуры удалить ее DROP TABLE #tmp

Таким образом, у Вас в базе фактически таблица не будет создана (и Вы ее нигде не увидите и соответственно не сможете обратиться к ней), она будет создана только для этой сессии, и обратиться к ней можно только из этой сессии, в которой Вы ее создали, т.е. даже если Вы создаете такую таблицу в одном окне запроса Management Studio то из другого окна Вы к ней не сможете обратиться. Это упрощает разработку процедуры и в некоторых случаях сильно ее ускоряет.

Надеюсь, эта статья поможет Вам разобраться, для чего нужны табличные функции, и временные таблицы, и как Вы их можете использовать на практике. Удачи!

Область видимости временных таблиц SQL SERVER

Давайте разберемся в области видимости временных таблиц.

Нам нужно выяснить когда временную таблицу можно увидеть и когда она будет отстутствовать, хотя мы её создавали.

В SQL SERVER существует два типа временных таблиц:

Глобальные — название начинается с ##
Локальные — название начинается с #

План исследования:

Подготовка скриптов для исследования
Исследование области видимости
Выводы

Создадим ХП из следующего скрипта:

SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE PROCEDURE [dbo].[test4] -- Add the parameters for the stored procedure here AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON; -- Insert statements for procedure here CREATE table ##test4 (id int, name varchar(50)) --SELECT * from ##test --SELECT object_id('tempdb..#temp') END GO /****** Object: StoredProcedure [dbo].[test3] Script Date: 01/22/2010 14:27:47 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE PROCEDURE [dbo].[test3] -- Add the parameters for the stored procedure here AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON; -- Insert statements for procedure here CREATE table #test3 (id int, name varchar(50)) --SELECT * from ##test --SELECT object_id('tempdb..#temp') END GO /****** Object: StoredProcedure [dbo].[test2] Script Date: 01/22/2010 14:27:47 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE PROCEDURE [dbo].[test2] -- Add the parameters for the stored procedure here AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON; -- Insert statements for procedure here SELECT * from ##test --SELECT object_id('tempdb..#temp') END GO /****** Object: StoredProcedure [dbo].[test] Script Date: 01/22/2010 14:27:47 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO -- ============================================= -- Author: Name -- Create date: -- Description: -- ============================================= CREATE PROCEDURE [dbo].[test] -- Add the parameters for the stored procedure here AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON; -- Insert statements for procedure here SELECT * from #test END

Рассмотрим для чего нужны хп:

[dbo].[test4] — Создаем глобальную временную таблицу
[dbo].[test3] — Создаем локальную временную таблицу
[dbo].[test2] — Выбираем данные из глобальной временной таблицы
[dbo].[test] — Выбираем данные из локальной временной таблицы

Выполняем скрипт по исследованию области видимости:

--создаем таблицы для просмотра из хп CREATE TABLE #test (id INT, name VARCHAR(256)) GO CREATE TABLE ##test (id INT, name VARCHAR(256)) GO --выполняем хп EXECUTE dbo.test GO EXECUTE dbo.test2 GO EXECUTE dbo.test3 GO EXECUTE dbo.test4 GO --выбираем данные из таблиц созданных в хп SELECT * FROM #test3 GO SELECT * FROM ##test4 GO --DROP TABLE ##test4 --DROP TABLE ##test

Получаем :

id name———— —————————————————————————————————————————————————————————————————————————————————————-

Msg 208, Level 16, State 0, Line 3Invalid object name ‘#test3’.id name———— —————————————————

(0 row(s) affected)

Выполняем в другом соединении :

--проверяем видимос

istomin.wordpress.com

Какую функцию выполняет в SQL временная таблица: примеры использования и удаления

От автора: ряд РСУБД поддерживают временные таблицы. В SQL временная таблица — это отличная функция, позволяющая сохранять и обрабатывать промежуточные результаты, используя те же возможности выбора, обновления и объединения данных, которые вы можете использовать со стандартными таблицами SQL Server.

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

Временные таблицы доступны в MS начиная с версии 3.23 и выше. Если вы используете более старую версию MySQL, вы не можете использовать временные таблицы, но в этих версиях доступны HEAP таблицы.

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

Пример

Ниже приведен пример использования временной таблицы.

Бесплатный курс по PHP программированию

Освойте курс и создайте динамичный сайт на PHP и MySQL с полного нуля, используя модель MVC

В курсе 39 уроков | 15 часов видео | исходники для каждого урока

Получить курс сейчас!

При запуске команды SHOW TABLES временная таблица не будет указана в списке. Теперь, если вы выйдете из сеанса MySQL и затем выполните команду SELECT, вы не найдете данных этой временной таблицы в базе данных. Сама временная таблица так же не будет существовать.

Удаление временных таблиц

По умолчанию все временные таблицы удаляются MySQL, когда соединение с базой данных завершается. Тем не менее, если вы хотите удалить таблицу до окончания сессии вы можете запустить команду DROP TABLE. Ниже приведен пример удаления временной таблицы.

Источник: https://www.tutorialspoint.com/

Редакция: Команда webformyself.

Хотите изучить MySQL?

Прямо сейчас посмотрите 24-х часовой курс по базе данных MySQL!

Смотреть курс

webformyself.com

Кэш временных таблиц в SQL Server (SQL Server temporary table caching)

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

В данной статье мы попытаемся разобраться как разрешать кэширование временных таблиц и сравним производительность для cached vs. non-cached temporary tables.

Опция кэширование временных таблиц доступна начиная с версии MS SQL 2005. При соблюдении определенных условий метаданные временной таблицы будут оставаться в tempdb даже когда запрос пользователь выполнил свою задачу. С точки зрения пользователя временная таблица больше недоступна, т.к. она удалена. Но, когда пользовательская сессия повторно выполняет подобный запрос, который создает временную таблицу, SQL сервер может использовать временную таблицу, которая была создана ранее.

Ниже перечислениы условия для включения опции использования кэша временных таблиц:— явно не объявлены ограничения (constraints)— DDL инструкция, которая затрагивает временную таблицу, не выполняется сразу после ее создания (прим. CREATE INDEX/CREATE STATISTICS)— временная таблица создана не с помощью динамического SQL— временная таблица создана внутри объекта БД (процедура или триггер)

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

Сравнение DDL производительности кэшированных и некэшированных таблиц

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

Для тестов использовался SQL Server 2016.

USE tempdb GO CREATE PROCEDURE dbo.sp_NewTmpTable AS BEGIN SET NOCOUNT ON; CREATE TABLE #Tmp (A INT IDENTITY(1,1), B varchar(20)) CREATE UNIQUE CLUSTERED INDEX AA ON #Tmp (A) END GO CREATE PROCEDURE dbo.sp_CachedTmpTable AS BEGIN SET NOCOUNT ON; CREATE TABLE #Tmp (A INT IDENTITY(1,1) PRIMARY KEY CLUSTERED, B varchar(20)) END GO

Сделаем запрос в sys.dm_os_performance_counters для получения Temp Tables Creation Rate. Служба MS SQL была предварительно перезапущена, поэтому результат рейта будет равен 0.

SELECT * FROM sys.dm_os_performance_counters WHERE counter_name = 'Temp Tables Creation Rate' AND OBJECT_NAME = 'SQLServer:General Statistics' GO

Результат:

Откроем новую сессию и вызовем процедуру dbo.sp_NewTmpTable 50 раз и проверим опять Temp Tables Creation Rate. Как видим результат равен 50, как следствие повторного вызова процедуры. В данном случае временная таблица не кэшируется (хоть и создана внутри процедуры), т.к. внутри процедуры сразу за инструкцией создания таблица следует вызов DDL инструкции.

EXEC tempdb.dbo.pr_NewTmpTable GO 50 SELECT * FROM sys.dm_os_performance_counters WHERE counter_name = 'Temp Tables Creation Rate' AND OBJECT_NAME = 'SQLServer:General Statistics' GO

Результат:

А теперь давайте повторим то же, но уже с процедурой dbo.sp_CachedTmpTable

EXEC tempdb.dbo.sp_CachedTmpTable GO 50 SELECT * FROM sys.dm_os_performance_counters WHERE counter_name = 'Temp Tables Creation Rate' AND OBJECT_NAME = 'SQLServer:General Statistics' GO

Результат:

Как видим, Temp Tables Creation Rate увеличился лишь на 1, т.к. временная таблица была кэширована и далее использована.

Предположим процедура sp_CachedTmpTable выполнена одновременно в 3-х разных сессиях. В таком случае Temp Tables Creation Rate должен быть увеличен на 3 единицы. В любой момент времени, когда параллельное выполнение sp_CachedTmpTable равно или менее 3-х, то Вы не увидите увеличение показателя Temp Tables Creation Rate. Таким образом, SQL сервер автоматически создаст кэшированные временные таблицы для удовлетворения одновременных запросов.

Чтобы показать DDL конкуренцию в tempdb давайте откроем 3 новых окна (сессии) в SSMS и начнем выполнение dbo.sp_NewTmpTable 50 000 раз в рамках каждой сессии примерно в то же время. Подобный тест проведем и для процедуры dbo.sp_CachedTmpTable. Более того проведем тест для следующей ad-hoc инструкции:

SET NOCOUNT ON; DECLARE @counter int = 1 WHILE @counter <= 50000 BEGIN CREATE TABLE #Tmp (A INT IDENTITY(1,1) PRIMARY KEY CLUSTERED, B varchar(20)) DROP TABLE #Tmp SET @counter += 1 END

Ниже показаны сравнительные результаты выполнения 3х вариантов в 3х параллельных сессиях:

	Сессия 1	Сессия 2	Сессия 3
tempdb.dbo.sp_NewTmpTable	1 мин. 8 сек.	1 мин. 7 сек.	1 мин. 8 сек
tempdb.dbo.sp_CachedTmpTable	28 сек.	28 сек.	28 сек.
ad-hoc запрос	1 мин. 26 сек.	1 мин. 37 сек.	1 мин. 36 сек.

Заключение

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

В наших тестах мы видим, что в процедуре dbo.sp_NewTmpTable не работает опция кэширования по причине того, что внутри процедуры присутствует явное именование индекса АА в конструкции. Если же мы изменим конструкцию создания PK и напишем «CREATE UNIQUE CLUSTERED INDEX», то SQL Server применит опцию кэширования при последующих вызовах этой процедуры в параллельных сессиях.

Стоит заметить, что не все последующие DLL операции предотвращают опцию кэширования. Исключением является «DROP TABLE» DDL инструкция. Это означает, что в процедуре dbo.sp_CachedTmpTable последующее использование «DROP TABLE», после создания временной таблицы, не запретит серверу кэширование и последующее использование таблицы #Tmp

Оригинал статьи

xandr.org.ua

sql - SQL Server/Oracle: частные временные таблицы

Таблицы Temp в SQL могут быть очень полезны, когда вам нужно объединить данные из разных источников, которые имеют общее поле слияния, но где вам нужно суммировать суммы до слияния, чтобы сравнить чистые итоговые значения для двух источников. В финансовой системе это полезно. Я был разочарован, когда перешел с SQL Server на Oracle, потому что потерял эту функциональность.

Ниже приведен пример реализации финансовой отчетности PeopleSoft. Бюджетный модуль (таблицы KK) и общая книга (журнал) должны иметь одинаковые балансы для фонда после того, как интерфейс был запущен между ними. В приведенном ниже запросе суммируются бюджетные суммы за счет фонда из таблиц KK и хранятся в таблице темпа, затем суммируются соответствующие суммы по фонду из главной книги, затем объединяются две таблицы с предварительным суммированием, чтобы можно было сравнить чистую сумму за один фонд от два источника - и перечисляет результаты только тогда, когда существует разница между суммами для фонда. В этом случае бюджетные модули и модули GL не синхронизированы. Это на самом деле довольно элегантное решение, и нет необходимости создавать глобальную таблицу темп, доступную другим для этого запроса/отчета.

Я надеюсь, что кто-то найдет это полезным. Это помогло мне в то время.

/*** START NESTED QUERY #1 ***/ /*** THE FOLLOWING CREATES TWO TEMP TABLES WITH NET AVAILABLE PER FUND ***/ /*** WITH ONE AMOUNT BASED ON KK TABLES AND ONE AMOUNT BASED ON ***/ /*** BUDGETARY GL BALANCES. THEN TEMP TABLES ARE MERGED BY FUND AND ***/ /*** NET DIFFERENCE CALCULATED-SELECTING FUNDS WITH DIFFERENCES. ***/ /*** IF BUDGET CHECKING IS COMPLETE AND JOURNALS CREATED AND POSTED ***/ /*** THERE SHOULD BE NO DIFFERENCES. ***/ --create a temp table with journal amounts summed by fund code CREATE TABLE #JRNLsum( FUND_CODE char(5), JRNLAMT decimal(19,2) ) INSERT INTO #JRNLsum (FUND_CODE, JRNLAMT) select FUND_CODE, sum(MONETARY_AMOUNT * -1) JRNLAMT FROM PS_JRNL_LN INNER JOIN PS_JRNL_HEADER ON PS_JRNL_LN.JOURNAL_ID = PS_JRNL_HEADER.JOURNAL_ID where ((ACCOUNT BETWEEN 430000 and 469999) and (FISCAL_YEAR >= '2009')) GROUP BY FUND_CODE order by FUND_CODE --create a temp table with KK ledger amounts summed by fund code CREATE TABLE #KKsum( FUND_CODE char(5), KKAMT decimal(19,2) ) INSERT INTO #KKsum (FUND_CODE, KKAMT) select FUND_CODE, sum(POSTED_TOTAL_AMT * -1) KKAMT from PS_LEDGER_KK where LEDGER like 'FUND_%' group by FUND_CODE order by FUND_CODE --join kk temp date to journal temp data, keep only --fund code, kk net amount, and journal net amount --and select only fund codes where there is a difference --between kk net amount and journal net amount select #KKsum.FUND_CODE, JRNLAMT, KKAMT from #JRNLsum INNER JOIN #KKsum on #KKsum.FUND_CODE=#JRNLsum.FUND_CODE where (JRNLAMT - KKAMT) <> 0.00 --drop the two temp tables drop table #KKsum drop table #JRNLsum /*** END NESTED QUERY #1

qaru.site

sql - временные таблицы в SQL

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

Но иногда вашей СУБД будет очень сложно оптимизировать сложные запросы. В этот момент у вас есть как минимум 5 вариантов:

измените свою схему или индексы, чтобы упростить оптимизатору выбор лучшего плана запроса.
подстройте свой SQL, чтобы заставить СУБД выбрать индексы, стратегии объединения и т.д., которые вы хотите, и обмениваться известными и неизвестными ошибками в вашем оптимизаторе СУБД.
используйте "подсказки", чтобы заставить СУБД выбирать индексы, стратегии объединения и т.д., которые вы хотите.
Получить желаемый план и использовать "сохраненный план", чтобы заставить его использовать СУБД.
использовать временные таблицы (или переменные таблицы и т.д.) для разложения сложных запросов на более простые промежуточные запросы

Нет hard- and- быстрого правила о том, какой вариант лучше всего подходит для любого конкретного запроса. Я использовал все вышеперечисленные стратегии. Я склонен выбирать подход temp table, когда у меня нет собственной схемы, поэтому я не могу ее изменить, и когда я не хочу зависеть от подсказок или настройки запроса или сохраненных планов (часто потому, что я не хочу подвергнуть себя изменениям в базовой схеме, сделанной позже).

Имейте в виду, что использование временных таблиц для разложения запросов даст вам sub- оптимальную производительность каждый раз. Но он обычно предсказуемо sub- оптимальный. В худшем случае использование временных таблиц не так плохо, как когда ваша СУБД выбирает плохой план для одного большого запроса. Это происходит на удивление часто, особенно перед лицом изменений в базовой схеме, изменения версии СУБД, различий между производителями и производственными различиями и т.д.

Лично я нахожу, что если запрос достигает уровня сложности, когда мне приходится наклоняться назад, чтобы заставить СУБД делать то, что я хочу, и если я чувствую, что ремонтопригодность приложения подвержена риску, Часто я буду использовать таблицы декомпозиции и temp, если я не могу изменить схему или индексы.

Конечно, теоретически вы не должны запускать дорогостоящие сложные запросы в своей базе данных OLTP, но на практике большинство приложений никогда не "чисты" OLTP-- всегда есть несколько сложных, hard- to- оптимизировать запросы в любом проекте OLTP.

qaru.site

sql-server - Временные таблицы в sql-сервере?

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

SQL Server предоставляет два типа временных таблиц, основанных на поведении и области действия таблицы. Это:

• Локальная таблица темпа

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

Локальная таблица темпов Локальные временные таблицы доступны только для текущего подключения для пользователя; и они автоматически удаляются, когда пользователь отключается от экземпляров. Локальное временное имя таблицы смотрится с помощью знака hash ("#" ). Глобальная таблица темпов Имя глобальных временных таблиц начинается с двойного хэша ("##" ). После того, как эта таблица была создана соединением, как постоянная таблица, она доступна любому пользователю любым подключением. Его можно удалить только после закрытия всех соединений.

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

• Когда мы выполняем большое количество манипуляций с строками в хранимых процедурах. • Это значение полезно для замены курсора. Мы можем сохранить данные набора результатов в временную таблицу, затем мы можем манипулировать данными оттуда. • Когда у нас сложная операция объединения.

Вопросы, которые следует помнить перед использованием временных таблиц -

• Временная таблица, созданная на tempdb SQL Server. Это отдельная база данных. Таким образом, это дополнительные накладные расходы и может вызвать проблемы с производительностью. • Количество строк и столбцов должно быть как минимум необходимым. • Таблицы необходимо удалить, когда они будут выполнены с их работой.

Альтернативный подход: переменная таблицы -

Альтернатива временной таблицы - это переменная таблицы, которая может выполнять все виды операций, которые мы можем выполнять в таблице Temp. Ниже приведен синтаксис использования переменной Table.

Когда использовать таблицу Variable Over Temp Table -

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

qaru.site