Artigos Banco de Dados Artigo SQL Magazine 31 - Stored procedures no MySQL - Parte 1

nt-family: Arial"> 

capa34

 

Clique aqui para ler todos os artigos desta edição

 

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)

 

Na listagem 3, temos um exemplo de uma stored procedure que mostra o uso de um parâmetro in. considerando que in é o padrão, não há necessidade de especificá-lo.

A variável de sessão @x é configurada dentro do procedimento, com base no parâmetro p, que é passado ao procedimento e permanece inalterado.

 

Listagem 3. exemplo de utilização de parâmetro do tipo in.

mysql> create procedure sp_in(p varchar(10)) set @x = p;

query ok, 0 rows affected (0.00 sec)

mysql> call sp_in(‘oi’);

query ok, 0 rows affected (0.00 sec)

mysql> select @x\g

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

@x: oi

1 row in set (0.00 sec)

 

Veja agora, na listagem 4, um exemplo utilizando um parâmetro do tipo out. note que foi necessário especificar que a variável é do tipo out, uma vez que este não é padrão.

Perceba que reinicializamos a variável @x somente para ter certeza de que o resultado final não seja um legado do procedimento anterior. Desta vez, o parâmetro p é alterado dentro do procedimento, enquanto que a variável de sessão é passada ao procedimento, pronta para receber o resultado.

 

Listagem 4. exemplo de utilização de parâmetro do tipo out.

mysql> set @x=’oi’;

query ok, 0 rows affected (0.00 sec)

mysql> create procedure sp_out(out p varchar(10)) set p=’ola’;

query ok, 0 rows affected (0.00 sec)

mysql> call sp_out(@x);

query ok, 0 rows affected (0.00 sec)

Para finalizar, a listagem 5 apresenta um exemplo que utiliza o parâmetro do tipo inout. Neste caso também é necessário especificar o tipo de parâmetro que será utilizado.

Neste exemplo, um parâmetro é passado ao procedimento, usado no cálculo e o resultado é disponibilizado para a variável de sessão @x.

 

Listagem 5. exemplo de utilização de parâmetro do tipo inout.

mysql> select @x\g

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

@x: ola

1 row in set (0.00 sec)

mysql> create procedure sp_inout(inout p int) set @x=p*2;

query ok, 0 rows affected (0.00 sec)

mysql> call sp_inout(2);

...

Quer ler esse conteúdo completo? Tenha acesso completo