Artigo SQL Magazine 31 - Stored procedures no MySQL - Parte 1

Stored procedures no MySQL – Parte 1

Ian Gilfilan

O mysql finalmente implementou as funcionalidades de stored procedures em sua versão 5.0. mas o que são exatamente stored procedures? este é o tipo de pergunta que faz com que profissionais de banco de dados que usam outros sgbds levantem as suas sobrancelhas. stored procedures foram integrados ao oracle, postgresql, db-2, sql server, entre outros, já faz anos, e por muito tempo, foi doloroso não tê-las para o mysql.

Uma stored procedure é um procedimento simples que é armazenado no servidor de banco de dados. desenvolvedores do mysql tiveram, desde tempos remotos, que escrever e armazenar estes procedimentos no servidor de aplicação (ou web), simplesmente porque não tinham outra opção. isto era limitativo. alguns diziam que existem duas escolas de pensamento: a primeira estipulava que a lógica do negócio deveria residir na aplicação, a segunda que deveria residir no banco de dados. porém, a maioria dos profissionais não adotou sempre o primeiro ou o segundo ponto de vista. como sempre,  existem situações em que os dois pontos de vista fazem sentido. infelizmente, alguns dos partidários mais fortes favoráveis ao primeiro ponto de vista (a lógica deve residir na aplicação), só o adotaram porque até o presente momento não tinham nenhuma outra escolha, e era a forma com a qual estavam acostumados. então, por que desejaríamos colocar lógica no servidor de banco de dados?

 Por que utilizar stored procedures?

 Porque rodarão em todos os ambientes e sem necessidade de recriar a lógica para cada aplicação desenvolvida. Desde o momento em que estão no servidor de banco de dados, independentemente do ambiente de aplicação usado, a stored procedure permanece consistente. Mesmo que a sua configuração envolva clientes diferentes e linguagens de programação diferentes, a lógica permanece em um só lugar. Desenvolvedores web normalmente fazem menos uso desta característica, pois o servidor web e o servidor de banco de dados geralmente são estreitamente ligados. porém, em organizações cliente-servidor complexas, esta é uma grande vantagem. os clientes estarão sempre automaticamente em sincronismo com a lógica de procedimento assim que a mesma tenha sido atualizada.

Podem também reduzir o tráfego da rede. De parte da lógica da aplicação for feita no servidor de banco de dados, não haverá necessidade de enviar result sets e novas consultas do servidor da aplicação para o servidor do banco de dados. O tráfego de rede é um gargalo freqüente, que causa problemas de desempenho, e as stored procedures podem ajudar a reduzir este problema. entretanto, freqüentemente acontece que o gargalo seja provocado pelo próprio servidor de banco de dados, portanto isto pode não ser uma grande vantagem. caberá ao desenvolvedor, em conjunto com o dba, identificar cada caso.

Um exemplo simples

 Uma stored procedure é, simplesmente, um conjunto de declarações sql. quase qualquer sql válido pode ser usada em uma stored procedure (com algumas exceções que veremos posteriormente). montemos agora uma stored procedure básica. a listagem 1 simplesmente dirá ‘oi’ na linguagem.

Listagem 1. uma stored procedure simples.

mysql> create procedure oi() select ‘oi’;

query ok, 0 rows affected (0.00 sec)

mysql> call oi()\g

***************** 1. row *****************

oi: oi

1 row in set (0.00 sec)

 Certamente essa stored procedure não é de grande utilidade. o importante aqui é entender que create procedure sp_name() define o procedimento e call sp_name() o chama para execução.

Parâmetros

O real benefício de uma stored procedure é obtido, é claro, quando você pode passar valores para ela e receber algum resultado. o conceito de parâmetros deverá ser familiar para qualquer um que tenha experiência com programação procedural. existem três tipos de parâmetro:

in: o padrão. este é um parâmetro de entrada para o procedimento. pode ser alterado dentro da procedure, mas permanecerá inalterado fora dele;

out: não é um parâmetro de entrada para o procedimento (será assumido null como valor de entrada), mas poderá ser modificado dentro da procedure e estará disponível fora dela após a alteração;

inout: tem as características de ambos os parâmetros in e out. um valor pode ser passado ao procedimento,  modificado no mesmo e também retornado.

O domínio de stored procedures requer conhecimentos de variáveis de sessão. a maioria de nós provavelmente já sabe usar variáveis de sessão, mas caso não saiba, o conceito é simples. Você pode designar um valor para uma variável, e recuperá-lo depois. A listagem 2 apresenta um exemplo em que configuramos a variável x para que a palavra “oi” possa ser repassada para um grupo de pessoas.

Listagem 2. exemplo de utilização de variável.

mysql> set @x=’oi’;

query ok, 0 rows affected (0.00 sec)

mysql> select @x\g

********************** 1. row **********************

@x: oi

1 row in set (0.00 sec)