Меню

Временное имя таблицы sql это

Временное имя таблицы sql это

Как использовать временные таблицы MySQL

База данных

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

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

  1. Что такое временная таблица MySQL? Как это работает?
  2. Особенности временной таблицы MySQL
  3. Основное использование
  4. Как создать временную таблицу на основе существующей таблицы
  5. Удалить временную таблицу MySQL
  6. Заключение

Что такое временная таблица MySQL? Как это работает?

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

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

Особенности временной таблицы MySQL

Временные таблицы MySQL имеют следующие особенности:

  1. Он хранится в памяти. Следовательно, он доступен в сеансе, в котором он был создан.
  2. Только пользователь, который создал таблицу, может получить доступ к таблице и использовать ее. Это означает, что несколько пользователей могут без конфликтов создать временную таблицу с похожими именами.
  3. Две временные таблицы с одинаковыми именами не могут существовать в одном сеансе одного и того же пользователя.
  4. Временная таблица имеет приоритет над основной. Например, если временная таблица содержит имя, аналогичное имени в основной таблице, основная таблица становится неактивной для этого сеанса. Если временная таблица удалена, основная таблица снова становится пригодной для использования. MySQL обычно не рекомендует называть временные таблицы подобными основным таблицам.
  5. Вы можете использовать DROP TABLE, чтобы удалить временную таблицу.

Основное использование

Давайте теперь обсудим, как мы можем реализовать временные таблицы MySQL и сценарии, в которых нам может потребоваться их использование.

ПРИМЕЧАНИЕ. Чтобы создать временную таблицу MySQL, пользователь должен иметь привилегию CREATE TEMPORARY TABLES.

Общий синтаксис создания временной таблицы MySQL следующий:

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

Например, чтобы создать временную таблицу, см. Запрос ниже:

CREATE DATABASE temporary;

USE temporary;

CREATE TEMPORARY TABLE users ( id INT NOT NULL AUTO_INCREMENT, username VARCHAR ( 50 ) , email VARCHAR ( 255 ) , PRIMARY KEY ( id ) ) ;

После создания таблицы пользователь может выполнять основные операции с таблицей, включая INSERT, UPDATE, DELETE, SELECT и DROP.

Например, давайте вставим некоторые данные во временную таблицу, созданную выше:

Как создать временную таблицу на основе существующей таблицы

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

Общий синтаксис выполнения такой операции следующий:

Удалить временную таблицу MySQL

Удаление временной таблицы из базы данных простое и использует аналогичный синтаксис для удаления таблиц в MySQL. Однако мы добавляем ключевое слово TEMPORARY, чтобы не удалять основную таблицу.

Например, чтобы удалить пользовательскую таблицу, созданную в приведенных выше примерах, мы используем запрос:

ПРИМЕЧАНИЕ. Если у вас есть временная таблица с тем же именем, что и у основной таблицы, убедитесь, что вы используете ключевое слово TEMPORARY в своем операторе DROP, чтобы избежать случайного удаления таблицы.

Заключение

В этом руководстве мы обсудили, что такое временные таблицы MySQL и как их использовать. Практикуйтесь, пока не освоите использование временных таблиц. Поскольку они могут пригодиться при выполнении сложных операций SQL.

Источник



Подзапросы и временные таблицы

Подзапросы

Во всех рассмотренных ранее примерах значения столбцов сравниваются с выражением, константой или набором констант. Кроме таких возможностей сравнения язык Transact-SQL позволяет сравнивать значения столбца с результатом другой инструкции SELECT. Такая конструкция, где предложение WHERE инструкции SELECT содержит одну или больше вложенных инструкций SELECT, называется . Первая инструкция SELECT подзапроса называется внешним запросом (outer query), а внутренняя инструкция (или инструкции) SELECT, используемая в сравнении, называется вложенным запросом (inner query). Первым выполняется вложенный запрос, а его результат передается внешнему запросу. Вложенные запросы также могут содержать инструкции INSERT, UPDATE и DELETE.

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

Независимый подзапрос может применяться со следующими операторами:

операторами ANY и ALL.

Подзапросы и операторы сравнения

Использование оператора равенства (=) в независимом подзапросе показано в примере ниже:

В этом примере происходит выборка имен и фамилий сотрудников отдела ‘Исследования’. Результат выполнения этого запроса:

Использование подзапроса с логическим оператором

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

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

Подзапросы и оператор IN

Оператор IN позволяет определить набор выражений (или констант), которые затем можно использовать в поисковом запросе. Этот оператор можно использовать в подзапросах при таких же обстоятельствах, т.е. когда вложенный запрос возвращает набор значений. Использование оператора IN в подзапросе показано в примере ниже:

Этот запрос аналогичен предыдущему. Каждый вложенный запрос может содержать свои вложенные запросы. Подзапросы такого типа называются подзапросами с многоуровневым вложением. Максимальная глубина вложения (т.е. количество вложенных запросов) зависит от объема памяти, которым компонент Database Engine располагает для каждой инструкции SELECT. В случае подзапросов с многоуровневым вложением система сначала выполняет самый глубокий вложенный запрос и возвращает полученный результат запросу следующего высшего уровня, который в свою очередь возвращает свой результат запросу следующего уровня над ним и т.д. Конечный результат выдается запросом самого высшего уровня.

Читайте также:  Черты либерализма консерватизма и социализма таблица

Запрос с несколькими уровнями вложенности показан в примере ниже:

В этом примере происходит выборка фамилий всех сотрудников, работающих над проектом Apollo. Самый глубокий вложенный запрос выбирает из таблицы ProjectNumber значение p1. Этот результат передается следующему вышестоящему запросу, который обрабатывает столбец ProjectNumber в таблице Works_on. Результатом этого запроса является набор табельных номеров сотрудников: (10102, 29346, 9031, 28559). Наконец, самый внешний запрос выводит фамилии сотрудников, чьи номера были выбраны предыдущим запросом.

Подзапросы и операторы ANY и ALL

Операторы ANY и ALL всегда используются в комбинации с одним из операторов сравнения. Оба оператора имеют одинаковый синтаксис:

Параметр operator обозначает оператор сравнения, а параметр query — вложенный запрос. Оператор ANY возвращает значение true (истина), если результат соответствующего вложенного запроса содержит хотя бы одну строку, удовлетворяющую условию сравнения. Ключевое слово SOME является синонимом ANY. Использование оператора ANY показано в примере ниже:

В этом примере происходит выборка табельного номера, номера проекта и названия должности для сотрудников, которые не затратили большую часть своего времени при работе над одним из проектов. Каждое значение столбца EnterDate сравнивается со всеми другими значениями этого же столбца. Для всех дат этого столбца, за исключением самой ранней, сравнение возвращает значение true (истина), по крайней мере, один раз. Строка с самой ранней датой не попадает в результирующий набор, поскольку сравнение ее даты со всеми другими датами никогда не возвращает значение true (истина). Иными словами, выражение «EnterDate > ANY (SELECT EnterDate FROM Works_on)» возвращает значение true, если в таблице Works_on имеется любое количество строк (одна или больше), для которых значение столбца EnterDate меньше, чем значение EnterDate текущей строки. Этому условию удовлетворяют все значения столбца EnterDate, за исключением наиболее раннего.

Оператор ALL возвращает значение true, если вложенный запрос возвращает все значения, обрабатываемого им столбца.

Настоятельно рекомендуется избегать использования операторов ANY и ALL. Любой запрос с применением этих операторов можно сформулировать лучшим образом посредством функции EXISTS, которая рассматривается далее в следующей статье. Кроме этого, семантическое значение оператора ANY можно легко принять за семантическое значение оператора ALL и наоборот.

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

— это объект базы данных, который хранится и управляется системой базы данных на временной основе. Временные таблицы могут быть локальными или глобальными. Локальные временные таблицы представлены физически, т.е. они хранятся в системной базе данных tempdb. Имена временных таблиц начинаются с префикса #, например #table_name.

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

Глобальные временные таблицы видимы любому пользователю и любому соединению и удаляются после отключения от сервера базы данных всех обращающихся к ним пользователей. В отличие от локальных временных таблиц имена глобальных временных таблиц начинаются с префикса ##. В примере ниже показано создание временной таблицы, называющейся project_temp, используя две разные инструкции языка Transact-SQL:

Два этих подхода похожи в том, что в обоих создается локальная временная таблица #project_temp. При этом таблица, созданная инструкцией CREATE TABLE, остается пустой, а созданная инструкцией SELECT заполняется данными из таблицы Project.

Источник

Табличные функции и временные таблицы в Transact-SQL

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

  1. Табличные функции в Transact-SQL – описание и примеры создания
  2. Пример создания простой табличной функции
  3. Пример создания табличной функции, в которой можно программировать
  4. Временные таблицы в Transact-SQL — описание и пример создания

Табличные функции в Transact-SQL – описание и примеры создания

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

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

Пример создания простой табличной функции

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

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

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

Получить данные из этой функции можно следующим образом:

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

Пример создания табличной функции, в которой можно программировать

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

Читайте также:  Форма заявления с таблицами

Теперь давайте обратимся к нашей функции, например, вот так

Временные таблицы в Transact-SQL — описание и пример создания

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

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

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

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

Заметка! Для комплексного изучения языка SQL и T-SQL рекомендую посмотреть мои видеокурсы по T-SQL, которые помогут Вам «с нуля» научиться работать с SQL и программировать на T-SQL в Microsoft SQL Server.

Источник

Временные таблицы в выделенном пуле SQL

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

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

Что собой представляют временные таблицы

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

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

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

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

Временные таблицы в выделенном пуле SQL

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

Создание временной таблицы

Для создания временной таблицы к имени таблицы добавляется префикс # . Пример:

Временные таблицы можно также создать с помощью CTAS точно таким же образом:

CTAS — мощная команда, которая особенно эффективна при использовании пространства журнала транзакций.

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

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

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

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

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

Разделение кода на модули

Так как временные таблицы можно просмотреть где угодно в сеансе пользователя, эту возможность можно использовать для модульной организации кода приложения.

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

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

В этой хранимой процедуре удаляется существующая таблица #stats_ddl. Это обеспечивает бесперебойную работу таблицы в случае ее повторного запуска на протяжении сеанса.

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

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

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

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

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

Источник

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

добавлено: 24 сен 11
понравилось:0
просмотров: 16175
комментов: 8

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

Существует два вида временных таблиц: локальные и глобальные. Они отличаются друг от друга именами, видимостью и доступностью. Имена локальных временных таблиц начинаются с одного символа (#); они видны только текущему соединению пользователя и удаляются, когда пользователь отключается от экземпляра SQL Server. Имена глобальных таблиц начинаются с двух символов номера (##); они видны любому пользователю и удаляются, когда все пользователи, которые на них ссылаются, отключаются от экземпляра SQL Server.

Читайте также:  Word объединить все таблицы

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

А теперь выдержка из BOL, которой я коснусь в этой статье:
Если локальная временная таблица создается хранимой процедурой или приложением, которые одновременно могут выполняться несколькими пользователями, компонент Database Engine должен иметь возможность различать таблицы, созданные разными пользователями. Компонент Database Engine делает это путем внутреннего присоединения числового суффикса к имени каждой локальной временной таблицы. Полное имя временной таблицы, хранящееся в таблице sysobjects базы данных tempdb, состоит из имени таблицы, заданного инструкцией CREATE TABLE, и сформированного системой числового суффикса. Для обеспечения возможности добавления суффикса значение параметра table_name, определенного как имя локальной временной таблицы, не должно содержать более 116 символов.

Действительно, если мы создадим временную таблицу и посмотрим её «ностоящее» наименование в tempdb, то мы увидем совсем не то имя, которое ей давали:


Как видно на рисунке, таблица создана с уникальным именем. Не смотря на то, что у таблицы такое странное наименование, мы можем обращаться к этой таблице по короткому имени, по тому с которым мы её создали. При этом из другого сеанса к этой таблице нельзя обращаться ни по короткому ни по полному имени, т.к. для другой сеанса наша таблица находится вне области видимости. При этом в другом сеансе можно спокойно создать таблицу с тем же именем не переживая, что сиквел выругается на то, что такой объект уже существует в БД. Но, как оказывается, не всё так гладко. Компонент Database Engine создаёт уникальное имя только для самой таблицы, а для констрейнтов этой таблицы в tempdb уникальность наименования не поддерживается. Для иллюстрации описанной проблемы, немного изменим предыдущий скрипт создания временной таблицы:

И теперь если запустить этот код в двух разных сеансах, то в первом код успешно отработает:

А во втором получим ошибку

Msg 2714, Level 16, State 5, Line 1 There is already an object named ‘df_dt’ in the database.
Msg 1750, Level 16, State 0, Line 1 Could not create constraint. See previous errors.

Констрейнт имеет име ‘df_dt’, т.е. мы не получили уникальность, как это происходит с именем таблицы. Именно поэтому мы и увидели столь неочевидную ошибку.

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

Продолжим наши эксперименты и попробуем вставить код создания таблицы в процедуру: Думаю многие из вас, перед выходом из процедуры, не «подчищают» за собой, т.к. временная таблица, созданная хранимой процедурой, удаляется автоматически при завершении хранимой процедуры. Для илюстрации этого можно запустить код вызова нашей процедуры и посмотреть, что лежит в tempdb ниже вызова процедуры: При этом мы не увидим нашей таблицы среди объектов tempdb. Но если запустить вызов процедуры в транзакции, то мы получим совершенно другую картину: Т.е. наши объекты не были автоматически удалены при выходе из процедуры и они «живут» в tempdb до завершения транзакции. При этом обратиться к нашей таблице из вне процедуры не выйдет, т.к. область видимости ограничивается телом процедуры. Теперь, если мы решим запустить нашу процедуру в одном сеансе дважды в транзакции: То опять получим ошибку, связанную с тем, что имя констрейнта не уникально:

Msg 2714, Level 16, State 5, Procedure Test_Procedure, Line 3 There is already an object named ‘df_dt’ in the database.
Msg 1750, Level 16, State 0, Procedure Test_Procedure, Line 3 Could not create constraint. See previous errors.

Мы знаем, что при удалении таблицы, удалятся и все её дочерние объекты (констрейнты, триггеры, индексы и т.д.). Казалось бы логично перед созданием таблицы проверять факт её наличия в БД и предварительно её удалять, чтоб удалились и все связанные с ней объекты. Но с временной таблицей этот номер не выйдет из-за её особенности создавать уникальное име в tempdb.

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

Причиной блокировки стал наш констрейнт, а т.к. блокировки Sch-M и Sch-S не совместимы( http://msdn.microsoft.com/ru-ru/library/ms186396.aspx), то второй сеанс ожидает высвобождения ресурсов.

Именно из-за своей неочевидности эти особенности работы с локальными временными таблицами заслуживают внимания. Проблему можно решить несколькими способами:
1) Удалять временные объекты, перед выходом из процедуры
2) Не создавать явное наименование для констрейнтов на временных таблицах, тогда наш код создания таблицы можно изменить на указанный ниже, и сиквел сам сгенерит своё уникальное имя для объектов:

Была даже идея оформить фидбэк, но это уже сделали до меня. ещё в далёком 2007-ом году (http://connect.microsoft.com/SQLServer/feedback/details/250046/temporary-tables-with-named-constraints). Официальный ответ: by design, но возможно в будущих релизах ситуация изменится.

Тесты я проводил на Сомневаюсь, что в ближайшее время ситуация изменится, поэтому будте внимательны при работе с временными таблицами.

Автор сильно выиграл бы, если бы добавил в заголовок блога или статей название СУБД, для которой он излагает материал.
Версии тоже бы не помешали.

Источник

Adblock
detector