MySQL: @переменная против переменной. В чем разница?

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

Примечание по PL/SQL (Oracle)

Преимущество можно увидеть в Oracle PL/SQL, где эти переменные имеют три разных области видимости:

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

Мой опыт в PL/SQL

Я разработал архитектуру, в которой весь код написан на PL/SQL. Эти процедуры вызываются из промежуточного уровня, написанного на Java. Существует два типа промежуточного уровня: один обрабатывает вызовы от клиента, который также написан на Java, другой — для вызовов из браузера. Клиентская часть полностью реализована на JavaScript. Для написания приложений на PL/SQL используется набор команд вместо HTML и JavaScript.

Я искал аналогичную функциональность для портирования кодов, написанных на PL/SQL, на другую базу данных. Ближайшая, которую я нашел, — Postgres. Однако все переменные имеют область видимости функции.

Мнение о @ в MySQL

Я рад видеть, что хотя бы эта функция @ существует в MySQL. Я не думаю, что Oracle создаст аналогичную функциональность, доступную в PL/SQL, для хранимых процедур MySQL, так как это может повлиять на продажи базы данных Oracle.

Вопрос, который вы подняли о том, как переменные обрабатываются в хранимых процедурах в MSSQL и MySQL, действительно актуален. В MSSQL переменные должны быть объявлены с помощью команды DECLARE, например: DECLARE @TEXT VARCHAR(25) = 'text'. Кроме того, в MSSQL можно объявлять переменные в любом блоке внутри процедуры, в то время как в MySQL все объявления переменных должны быть сделаны вверху.

Одной из проблем, которую вы упомянули, является использование конструкции SET @variable в хранимых процедурах MySQL. Это действительно можно считать рискованным, поскольку переменные в MySQL не имеют области видимости и могут сохраняться через границы областей. Это похоже на ситуации в JavaScript, когда переменные объявляются без префикса var, что приводит к созданию глобальных переменных и неожиданным коллизиям.

Надеюсь, что разработчики MySQL рассмотрят возможность добавления синтаксиса DECLARE @Variable на различных уровнях блоков в хранимых процедурах. Обратите внимание на символ @. Префикс @ помогает отделить имена переменных от имен столбцов таблиц, которые часто совпадают. Конечно, можно использовать префиксы "v" или "l_", но @ — это удобный и лаконичный способ синхронизировать имя переменной с именем столбца, из которого вы хотите извлечь данные, не создавая конфликты.

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

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

@Xybo: Я не понимаю, почему использование @переменных в хранимых процедурах может быть рискованным. Можешь объяснить понятия "область видимости" и "границы" немного проще (для меня как для новичка)?