Aula 16: Stored Procedures — procedimentos armazenados no MySQL

Em ambientes corporativos de banco de dados, a busca por desempenho, segurança e manutenibilidade leva inevitavelmente ao uso de Stored Procedures — blocos de código SQL pré-compilados que residem no servidor e podem ser invocados sob demanda. Nesta décima sexta aula do curso MySQL — Do Zero ao Avançado, você irá mergulhar nesse recurso fundamental, compreendendo desde a sintaxe de criação até a implementação de lógicas complexas com cursores e tratamento condicional. As Stored Procedures representam um dos pilares da programação no lado do servidor, permitindo encapsular regras de negócio, reduzir o tráfego de rede e fortalecer a camada de dados com validações que independem da aplicação cliente.

A relevância das Stored Procedures no ecossistema MySQL vai muito além da teoria. Quem atua com segurança da informação sabe que restringir o acesso direto às tabelas e expor apenas rotinas controladas é uma das medidas mais eficazes contra SQL Injection e acessos não autorizados. Para o profissional de infraestrutura, a possibilidade de otimizar o plano de execução de uma consulta uma única vez e reutilizá-la indefinidamente representa ganho real de performance em sistemas com milhares de transações por minuto. E para o desenvolvedor full‑stack, armazenar lógica no banco elimina duplicação de código entre diferentes módulos da aplicação — seja ela escrita em Python, Java, PHP ou qualquer outra linguagem.

Ao concluir esta aula, você será capaz de criar suas próprias Stored Procedures, definir parâmetros de entrada e saída, utilizar estruturas de controle como IF, LOOP, WHILE e cursores, além de gerenciar o ciclo de vida completo dessas rotinas. Todo o conteúdo é apresentado com exemplos práticos reais, executados em um ambiente MySQL 8.0 padronizado, idêntico ao que utilizamos em consultorias e treinamentos da JRT Technology Solutions. O pré-requisito imediato é ter concluído as aulas anteriores, especialmente sobre funções de agregação, subconsultas e joins avançados, pois faremos uso intensivo desses recursos dentro das procedures.

O que você vai aprender nesta aula

• Definir o conceito e o ciclo de vida de uma Stored Procedure no MySQL.
• Criar procedures simples e invocá-las com CALL.
• Trabalhar com parâmetros IN, OUT e INOUT para comunicação bidirecional.
• Declarar variáveis locais e manipular dados com SELECT … INTO.
• Implementar lógica condicional (IF-THEN-ELSE) e laços (WHILE, REPEAT, LOOP).
• Percorrer conjuntos de registros com cursores (CURSOR) e handlers de continuação.
• Gerenciar procedures existentes: listar, visualizar a definição, alterar e excluir.
• Diagnosticar e corrigir os erros mais comuns ao implementar Stored Procedures.

Pré-requisitos e Ambiente

Para seguir esta aula do início ao fim, você precisa de um servidor MySQL 8.0 (ou superior) instalado e acessível com privilégios de CREATE ROUTINE e EXECUTE. O cliente de linha de comando mysql deve estar funcional, e recomendamos utilizar o editor de sua preferência para escrever os scripts — no decorrer da aula demonstraremos os comandos diretamente no terminal, mas todas as procedures também podem ser criadas por meio do MySQL Workbench ou de clientes como DBeaver. O banco de dados de exemplo que utilizaremos será o empresa, com as tabelas funcionarios e departamentos. Se você já executou as aulas anteriores no mesmo ambiente, pode simplesmente reutilizar a base existente; caso contrário, os scripts de criação são fornecidos no primeiro passo prático.

O que são Stored Procedures e por que utilizá-las

Uma Stored Procedure é um conjunto nomeado de instruções SQL armazenado no dicionário de dados do servidor MySQL. Diferentemente de uma consulta ad‑hoc digitada no terminal, a procedure é compilada na primeira execução e seu plano de acesso é armazenado em cache, permitindo que chamadas subsequentes evitem a sobrecarga de análise sintática e otimização. Essa característica, somada ao fato de que todo o código trafega pela rede apenas na forma de um comando CALL, reduz significativamente a latência em cenários onde múltiplas instruções SQL seriam disparadas individualmente pela aplicação. Em projetos de alta criticidade na JRT Technology Solutions, encapsulamos rotinas de fechamento contábil e geração de relatórios justamente em procedures para garantir atomicidade e previsibilidade de desempenho.

Do ponto de vista da segurança, as Stored Procedures permitem aplicar o princípio do menor privilégio: o usuário da aplicação não recebe permissão de SELECT, INSERT ou DELETE diretamente sobre as tabelas, mas apenas de executar as rotinas previamente auditadas. Isso impede que uma vulnerabilidade de injeção consiga modificar estruturas ou extrair dados arbitrários, pois o invasor ficará restrito ao que a procedure oferece. Além disso, a manutenção de regras de negócio fica centralizada; uma correção no cálculo de bônus, por exemplo, é feita uma única vez no banco de dados e reflete imediatamente em todas as aplicações que consomem a procedure.

Sintaxe básica para criação de Stored Procedures

Para evitar que o ponto‑e‑vírgula utilizado como terminador das instruções SQL dentro da procedure seja interpretado como fim do comando durante a criação, o MySQL exige que troquemos temporariamente o delimitador padrão. O padrão da indústria é utilizar DELIMITER $$ ou DELIMITER //. A criação propriamente dita é feita com o comando CREATE PROCEDURE, seguido pelo nome da rotina, parâmetros opcionais entre parênteses e o bloco BEGIN … END que encapsula o corpo. Cada parâmetro deve ser precedido por uma direção: IN (entrada, padrão), OUT (retorno) ou INOUT (entrada e saída). Após a definição, restauramos o delimitador para o ; habitual.

-- Sintaxe genérica
DELIMITER $$
CREATE PROCEDURE nome_procedure( [IN|OUT|INOUT] param1 TIPO, ... )
BEGIN
    -- instruções SQL;
END$$
DELIMITER ;

A instrução CALL nome_procedure(…) invoca a rotina. Para remover uma procedure existente, utilizamos DROP PROCEDURE IF EXISTS nome_procedure. A cláusula IF EXISTS é particularmente útil em scripts de deploy automatizado para evitar que o job falhe quando a rotina ainda não foi criada — prática que adotamos em todos os pipelines de CI/CD que gerenciamos para clientes da JRT.

Criando e executando sua primeira Stored Procedure

Vamos começar com a base de dados de exemplo. Conecte‑se ao MySQL como usuário administrativo e execute o script abaixo. Ele cria o banco empresa, a tabela departamentos e a tabela funcionarios com alguns registros iniciais. Todo o conteúdo a seguir foi projetado para ser copiado e colado diretamente no seu terminal, respeitando a ordem exata de execução.

-- Preparação do ambiente
CREATE DATABASE IF NOT EXISTS empresa;
USE empresa;

CREATE TABLE departamentos (
    id      INT AUTO_INCREMENT PRIMARY KEY,
    nome    VARCHAR(100) NOT NULL
);

CREATE TABLE funcionarios (
    id          INT AUTO_INCREMENT PRIMARY KEY,
    nome        VARCHAR(150) NOT NULL,
    salario     DECIMAL(10,2) NOT NULL,
    depto_id    INT,
    FOREIGN KEY (depto_id) REFERENCES departamentos(id)
);

INSERT INTO departamentos (nome) VALUES ('Tecnologia'), ('Financeiro'), ('Recursos Humanos');
INSERT INTO funcionarios (nome, salario, depto_id) VALUES
    ('Alice Almeida', 7500.00, 1),
    ('Bruno Barreto', 5200.00, 2),
    ('Carla Carvalho', 6200.00, 1),
    ('Daniel Duarte', 4800.00, 3),
    ('Eduarda Esteves', 9100.00, 2);

Query OK, 1 row affected (0,01 sec)
Query OK, 0 rows affected (0,02 sec)
Query OK, 0 rows affected (0,03 sec)
Query OK, 3 rows affected (0,00 sec)
Records: 3  Duplicates: 0  Warnings: 0
Query OK, 5 rows affected (0,00 sec)
Records: 5  Duplicates: 0  Warnings: 0

Agora criaremos uma procedure simples que retorna a quantidade total de funcionários. Esta rotina não recebe parâmetros e utiliza SELECT COUNT(*) como retorno direto. É a forma mais elementar de encapsular uma consulta que será reutilizada frequentemente.

-- Primeira Stored Procedure: contar funcionários
DELIMITER $$
CREATE PROCEDURE sp_total_funcionarios()
BEGIN
    SELECT COUNT(*) AS total FROM funcionarios;
END$$
DELIMITER ;

Para executá‑la, basta utilizar o comando CALL. O resultado será idêntico ao de uma consulta comum, mas sem que a aplicação precise conhecer a estrutura das tabelas envolvidas.

CALL sp_total_funcionarios();

+-------+
| total |
+-------+
|     5 |
+-------+
1 row in set (0,00 sec)

Stored Procedures com parâmetros de entrada (IN)

A verdadeira potência das Stored Procedures aparece quando adicionamos parâmetros que tornam a rotina dinâmica. O parâmetro IN é o modo padrão: seu valor é passado pelo chamador e utilizado internamente, mas não é devolvido ao final. Vamos criar uma procedure que retorna os funcionários de um determinado departamento, recebendo o nome do departamento como argumento. Para isso, precisaremos de um JOIN entre as tabelas e uma cláusula WHERE.

DELIMITER $$
CREATE PROCEDURE sp_funcionarios_por_depto(IN nome_depto VARCHAR(100))
BEGIN
    SELECT f.nome, f.salario
    FROM funcionarios f
    INNER JOIN departamentos d ON f.depto_id = d.id
    WHERE d.nome = nome_depto;
END$$
DELIMITER ;

Teste a chamada com diferentes valores para observar a filtragem dinâmica. O parâmetro é passado entre parênteses, exatamente como nas funções comuns.

CALL sp_funcionarios_por_depto('Tecnologia');

+------------------+---------+
| nome             | salario |
+------------------+---------+
| Alice Almeida    | 7500.00 |
| Carla Carvalho   | 6200.00 |
+------------------+---------+
2 rows in set (0,00 sec)

Parâmetros de saída (OUT) e entrada/saída (INOUT)

Além de receber valores, muitas vezes precisamos que uma procedure devolva resultados escalares — média salarial, total de afetados por uma atualização, ou mesmo um status de sucesso. Para isso, declaramos parâmetros com a direção OUT. O valor atribuído a esse parâmetro dentro da procedure estará disponível na sessão chamadora após a execução. O modo INOUT permite que o mesmo parâmetro seja fornecido com um valor inicial e posteriormente modificado, reunindo as duas direções em um único argumento.

A procedure abaixo calcula a média salarial de todos os funcionários e devolve o resultado em um parâmetro de saída. Note que o chamador precisa passar uma variável de sessão (@media) para capturar o valor.

DELIMITER $$
CREATE PROCEDURE sp_media_salarial(OUT media DECIMAL(10,2))
BEGIN
    SELECT AVG(salario) INTO media FROM funcionarios;
END$$
DELIMITER ;

CALL sp_media_salarial(@media);
SELECT @media AS media_salarial;

+---------------+
| media_salarial|
+---------------+
|       6160.00 |
+---------------+
1 row in set (0,00 sec)

No caso do INOUT, suponha que desejamos aplicar um reajuste percentual a uma faixa salarial e retornar o novo valor atualizado. O parâmetro recebe o salário atual e sai com o salário reajustado.

DELIMITER $$
CREATE PROCEDURE sp_reajustar(INOUT salario_atual DECIMAL(10,2), IN percentual DECIMAL(5,2))
BEGIN
    SET salario_atual = salario_atual + (salario_atual * percentual / 100);
END$$
DELIMITER ;

SET @sal = 5000.00;
CALL sp_reajustar(@sal, 10);
SELECT @sal AS novo_salario;

+--------------+
| novo_salario |
+--------------+
|      5500.00 |
+--------------+
1 row in set (0,00 sec)

Variáveis, estruturas de controle e cursores

Para implementar lógica condicional e iterativa dentro das Stored Procedures, o MySQL oferece um conjunto robusto de comandos procedurais. Variáveis locais são declaradas com DECLARE e devem aparecer antes de qualquer outro comando no bloco BEGIN. O escopo de uma variável é limitado ao bloco onde foi criada. As principais estruturas de controle incluem IF-THEN-ELSE, CASE, WHILE, REPEAT e LOOP (com LEAVE para saída).

Cursores são essenciais para percorrer conjuntos de registros linha a linha. Sua utilização segue um ciclo previsível: DECLARE CURSOR para associar uma consulta, DECLARE CONTINUE HANDLER para tratar o fim do conjunto, OPEN cursor, FETCH repetido em laço e CLOSE cursor. A procedure abaixo exemplifica o uso completo: ela percorre todos os departamentos, calcula a média salarial de cada um e insere esses resultados em uma tabela de log.

-- Tabela de log
CREATE TABLE log_media_depto (
    id INT AUTO_INCREMENT PRIMARY KEY,
    nome_depto VARCHAR(100),
    media DECIMAL(10,2),
    data_calculo DATETIME
);

-- Procedure com cursor
DELIMITER $$
CREATE PROCEDURE sp_calcular_media_por_depto()
BEGIN
    DECLARE v_depto_nome VARCHAR(100);
    DECLARE v_media DECIMAL(10,2);
    DECLARE v_fim INT DEFAULT 0;

    -- Cursor que traz o nome do depto e a média salarial
    DECLARE cur CURSOR FOR
        SELECT d.nome, AVG(f.salario)
        FROM funcionarios f
        INNER JOIN departamentos d ON f.depto_id = d.id
        GROUP BY d.nome;

    DECLARE CONTINUE HANDLER FOR NOT FOUND SET v_fim = 1;

    OPEN cur;

    read_loop: LOOP
        FETCH cur INTO v_depto_nome, v_media;
        IF v_fim = 1 THEN
            LEAVE read_loop;
        END IF;
        INSERT INTO log_media_depto (nome_depto, media, data_calculo)
        VALUES (v_depto_nome, v_media, NOW());
    END LOOP;

    CLOSE cur;
END$$
DELIMITER ;

A execução da procedure populará a tabela de log com uma linha por departamento. Validamos o resultado com um simples SELECT:

CALL sp_calcular_media_por_depto();
SELECT * FROM log_media_depto;

+----+-------------------+---------+---------------------+
| id | nome_depto        | media   | data_calculo        |
+----+-------------------+---------+---------------------+
|  1 | Tecnologia        | 6850.00 | 2026-07-17 14:22:10 |
|  2 | Financeiro        | 7150.00 | 2026-07-17 14:22:10 |
|  3 | Recursos Humanos  | 4800.00 | 2026-07-17 14:22:10 |
+----+-------------------+---------+---------------------+
3 rows in set (0,00 sec)

Gerenciando Stored Procedures: listar, visualizar e remover

Com o tempo, o número de Stored Procedures tende a crescer, principalmente em bases que suportam dezenas de microsserviços. Saber localizá‑las rapidamente é crucial para manutenção. O MySQL armazena as definições das rotinas na tabela INFORMATION_SCHEMA.ROUTINES. Podemos filtrar pelo nome do banco e pelo tipo de rotina para obter uma lista completa.

-- Listar todas as procedures do banco 'empresa'
SELECT ROUTINE_NAME, CREATED, LAST_ALTERED
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_SCHEMA = 'empresa'
  AND ROUTINE_TYPE = 'PROCEDURE';

+-----------------------------------+---------------------+---------------------+
| ROUTINE_NAME                      | CREATED             | LAST_ALTERED        |
+-----------------------------------+---------------------+---------------------+
| sp_calcular_media_por_depto       | 2026-07-17 14:22:04 | 2026-07-17 14:22:04 |
| sp_funcionarios_por_depto         | 2026-07-17 14:21:33 | 2026-07-17 14:21:33 |
| sp_media_salarial                 | 2026-07-17 14:21:45 | 2026-07-17 14:21:45 |
| sp_reajustar                      | 2026-07-17 14:21:50 | 2026-07-17 14:21:50 |
| sp_total_funcionarios             | 2026-07-17 14:21:21 | 2026-07-17 14:21:21 |
+-----------------------------------+---------------------+---------------------+
5 rows in set (0,00 sec)

Para visualizar o código‑fonte de uma procedure, utilizamos SHOW CREATE PROCEDURE. A saída inclui o definidor, o delimitador utilizado e o corpo completo. Essa informação é valiosa durante auditorias e revisões de segurança.

SHOW CREATE PROCEDURE sp_total_funcionarios\G

*************************** 1. row ***************************
           Procedure: sp_total_funcionarios
            sql_mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,...
    Create Procedure: CREATE DEFINER=`root`@`localhost` PROCEDURE `sp_total_funcionarios`()
BEGIN
    SELECT COUNT(*) AS total FROM funcionarios;
END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: utf8mb4_0900_ai_ci
1 row in set (0,00 sec)

Para excluir uma procedure que não é mais necessária, usa‑se DROP PROCEDURE IF EXISTS. Em scripts de atualização de schema, essa cláusula previne falhas garantindo que a remoção seja idempotente.

DROP PROCEDURE IF EXISTS sp_reajustar;

Alterações no corpo de uma procedure não são feitas com ALTER PROCEDURE (que só modifica características como comentário e definidor), mas sim recriando a rotina. O procedimento recomendado para deploy é encapsular a criação com uma verificação de existência:

DROP PROCEDURE IF EXISTS sp_nova_procedure;
DELIMITER $$
CREATE PROCEDURE sp_nova_procedure() ... END$$
DELIMITER ;

Verificando a Instalação / Testando a Configuração

Antes de prosseguir para tópicos avançados, é essencial validar que o ambiente está configurado corretamente para dar suporte às Stored Procedures. Execute cada etapa abaixo e confira se as saídas correspondem. Primeiro, certifique‑se de que o serviço mysqld está rodando e que você consegue se conectar com privilégios adequados.

mysql -u root -p --execute "SELECT VERSION();"

+-----------+
| VERSION() |
+-----------+
| 8.0.35-0  |
+-----------+

Em seguida, verifique se o seu usuário possui os privilégios CREATE ROUTINE e EXECUTE. O comando SHOW GRANTS exibe as concessões ativas para a sessão corrente. Na listagem, procure por essas duas permissões no banco empresa (ou em *.*, caso sejam globais).

SHOW GRANTS FOR CURRENT_USER();

+-------------------------------------------------------------------+
| Grants for root@localhost                                         |
+-------------------------------------------------------------------+
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD,       |
| SHUTDOWN, PROCESS, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES,|
| SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE,             |
| REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW,    |
| CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER,       |
| CREATE TABLESPACE, CREATE ROLE, DROP ROLE ON *.* TO `root`@`%`...|
+-------------------------------------------------------------------+
1 row in set (0,00 sec)

Agora, teste a execução de uma procedure que já criamos anteriormente. Se a chamada retornar o resultado esperado sem erros de sintaxe ou privilégio, seu ambiente está plenamente funcional.

CALL sp_total_funcionarios();

Por fim, confira se as definições estão corretamente armazenadas no dicionário de dados consultando a INFORMATION_SCHEMA.ROUTINES e verificando a coluna ROUTINE_DEFINITION.

SELECT ROUTINE_NAME, ROUTINE_DEFINITION
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_SCHEMA = 'empresa'
  AND ROUTINE_NAME = 'sp_total_funcionarios'\G

*************************** 1. row ***************************
   ROUTINE_NAME: sp_total_funcionarios
ROUTINE_DEFINITION: BEGIN
    SELECT COUNT(*) AS total FROM funcionarios;
END
1 row in set (0,01 sec)

Erros Comuns e Como Resolver

Mesmo profissionais experientes encontram obstáculos ao trabalhar com Stored Procedures. Abaixo, os quatro erros mais reportados por nossos alunos e clientes de suporte da JRT Technology Solutions, com diagnóstico e solução detalhados.

• ERROR 1064 (42000): You have an error in your SQL syntax; check the manual…
  Causa: Falta da troca de delimitador antes do BEGIN. O MySQL interpreta o primeiro ; interno como término do CREATE PROCEDURE, gerando uma instrução incompleta.
  Solução: Sempre inicie com DELIMITER $$ (ou outro caractere) e finalize com $$ antes de restaurar para ;. Revise o bloco para garantir que todos os terminadores internos sejam ; e que o final da procedure seja o delimitador customizado.
• ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration…
  Causa: O MySQL, por padrão, exige que rotinas que não declaram explicitamente essas características estejam associadas a uma variável de sistema log_bin_trust_function_creators habilitada. Embora o erro mencione “function”, ele também afeta a criação de procedures em ambientes com binary logging ativo.
  Solução: Inclua uma cláusula de característica, como READS SQL DATA ou MODIFIES SQL DATA, após o cabeçalho da procedure. Exemplo: CREATE PROCEDURE nome() READS SQL DATA BEGIN … END. Alternativamente, configure SET GLOBAL log_bin_trust_function_creators = 1, mas avalie o impacto de segurança.
• ERROR 1304 (42000): PROCEDURE sp_media_salarial already exists
  Causa: Tentativa de criar uma procedure com nome duplicado no mesmo banco de dados.
  Solução: Utilize DROP PROCEDURE IF EXISTS nome antes de recriar, ou opte por gerar nomes versionados (ex.: sp_calculo_v2). Em pipelines de CI/CD, sempre contemple a remoção condicional.
• ERROR 1172 (42000): Result consisted of more than one row
  Causa: Dentro de uma procedure, um SELECT … INTO retornou múltiplas linhas, o que é proibido. A variável escalar não pode receber um conjunto de valores.
  Solução: Reprojete a consulta para retornar uma única linha (agregando com LIMIT 1 ou filtrando por chave primária) ou utilize um cursor para iterar sobre o resultado.

Boas Práticas e Dicas Avançadas

Em implantações reais, a qualidade das Stored Procedures impacta diretamente a estabilidade do sistema. A primeira recomendação é manter o código das procedures versionado fora do banco, em repositórios Git, aplicando-as ao banco por meio de ferramentas de migração como Flyway ou Liquibase. Isso garante rastreabilidade e reprodutibilidade. Em nossos projetos na JRT Technology Solutions, toda procedure passa por revisão de código e testes automatizados que simulam chamadas com dados de produção anonimizados.

Outra prática indispensável é o tratamento de erros com DECLARE … HANDLER. Sempre inclua handlers para condições como SQLEXCEPTION e NOT FOUND, revertendo transações explícitas quando necessário. Procedures que manipulam dados financeiros devem seguir o princípio ACID: inicie com START TRANSACTION, realize todas as operações, verifique condições com IF e finalize com COMMIT ou ROLLBACK. Abaixo, uma tabela com os principais comandos e características de procedures que você pode usar como referência rápida.

Quanto à performance, evite concatenar SQL dinâmico (PREPARE/EXECUTE) dentro de procedures, a menos que seja estritamente necessário, pois isso impede que o otimizador pré‑compile o plano de execução. Prefira consultas parametrizadas com placeholders e tire proveito do cache de plano. Em cenários de alto volume, monitore as métricas de desempenho das procedures por meio do Performance Schema e da view sys.x$statement_analysis, identificando rotinas que consomem mais tempo ou acessos a disco.

Resumo da Aula 16

Nesta aula, você dominou a criação e o gerenciamento de Stored Procedures no MySQL, desde os conceitos fundamentais até a implementação de lógicas avançadas com cursores e handlers. Aprendemos a declarar parâmetros IN, OUT e INOUT, a encapsular regras de negócio no servidor e a auditar o código existente por meio de consultas ao dicionário de dados. Com as práticas e exemplos aqui apresentados, você está apto a refatorar scripts dispersos em procedimentos centralizados, melhorando a segurança e a performance das suas aplicações.

Como próximos passos, recomendamos que você exercite a criação de procedures que envolvam transações múltiplas e replicação em cluster, ambientes onde o tratamento de erros se torna ainda mais crítico. Lembre‑se de que a JRT Technology Solutions oferece treinamentos corporativos e consultoria especializada em MySQL, incluindo otimização de procedures e migração de bases legadas; nossos especialistas utilizam diariamente os conceitos desta aula em projetos de larga escala.

Na Aula 17, daremos continuidade ao tema de programação no servidor abordando Funções Definidas pelo Usuário (UDFs) — que compartilham muitas semelhanças com procedures, mas são invocadas diretamente em expressões SQL. Prepare o ambiente e revise os tipos de retorno, pois a próxima aula será prática intensiva.