Firebird, fazendo valer o lado do servidor

evaldoavelar

O Firebird traz dezenas de recursos que podem deixar as aplicações cliente-servidor muito mais rápidas, de forma que a maior parte do processamento se concentre realmente no lado do servidor, melhorando o tráfego de dados na rede e não exigindo muito da plataforma onde está o cliente.

[ Hits: 27.262 ]

Por: Evaldo Avelar Marques em 20/07/2009 | Blog: http://evaldoavelar.blogspot.com/

0 0

Denuncie Favoritos Indicar Impressora

Stored Procedures

Primeiro criaremos algumas tabelas de exemplo:

CREATE TABLE FUNCIONARIOS (
    ID       INTEGER,
    NOME     VARCHAR(100),
    SALARIO  FLOAT
);

CREATE TABLE HISTORICO (
    ID_FUNCIONARIO    INTEGER,
    DATA              DATE,
    SALARIO_ANTERIOR  FLOAT,
    NOVO_SALARIO      FLOAT
);

Popularemos a tabela FUNCIONARIOS:

INSERT INTO FUNCIONARIOS (ID, NOME, SALARIO) VALUES (1, 'José', 20);
INSERT INTO FUNCIONARIOS (ID, NOME, SALARIO) VALUES (2, 'Maria', 50);
INSERT INTO FUNCIONARIOS (ID, NOME, SALARIO) VALUES (3, 'Marta', 100);

COMMIT WORK

A stored procedure

Supondo que queremos dar aumento de x% para um de nossos empregados, se fosse realizar essa rotina na sua aplicação, como seria?

Provavelmente você enviaria uma Query com o comando update para o Firebird para fazer essa atualização, não é verdade?

UPDATE FUNCIONARIOS SET SALARIO= SALARIO +( (:PERCENT*100) / SALARIO ) WHERE ID = :ID

E como ficaria se criássemos uma Stored Procedure para isso?

Então vamos escrever a nossa Stored Procedure:

CREATE PROCEDURE DAR_AUMENTO ( ID INTEGER, PERCENT SMALLINT) AS BEGIN UPDATE FUNCIONARIOS SET SALARIO= SALARIO +( (:PERCENT*100) / SALARIO ) WHERE ID = :ID ; suspend; END

As variáveis ID e PERCENT serão passadas para a Procedure quando as executarmos. E aplicaremos os ":" para usar as variáveis dentro da Procedure. Vamos a um exemplo: precisamos dar um aumento de 30% para a Marta (lembre se o id da Marta é 3).

Comando:

EXECUTE PROCEDURE DAR_AUMENTO(3,30);

Saída: sucesss....

Ok, tudo certo! Com o aumento Marta agora recebe 130.

Mas e se tentarmos dar aumento para um funcionário que não existe? O que fazer?

Então criaremos uma Exception!

CREATE EXCEPTION EXP_FUNC_NOT_EXIST 'Funcionário não existe';

E agora atualizaremos nossa Procedure:

ALTER PROCEDURE DAR_AUMENTO (
    ID INTEGER,
    PERCENT SMALLINT)
AS
DECLARE VARIABLE FUNC INTEGER;
BEGIN
  SELECT ID FROM FUNCIONARIOS WHERE ID = :ID INTO :FUNC;

  IF (FUNC IS NULL ) THEN
    EXCEPTION EXP_DAR_AUMENTO  ;
  ELSE
    uPDATE FUNCIONARIOS SET SALARIO= SALARIO +( (:PERCENT*100) / SALARIO ) WHERE ID = :ID ;
END

Pronto! Sempre que não existir o funcionário seremos avisados.

Comando:

EXECUTE PROCEDURE DAR_AUMENTO(8,30);

Saída:

EXP_DAR_AUMENTO.
Funcionário não existe.
At procedure 'DAR_AUMENTO'

Você poderia tratar essa exceção na sua aplicação.

Página anterior Próxima página

Páginas do artigo

   1. Recursos
   2. Stored Procedures
   3. Triggers
   4. Views

Outros artigos deste autor

É possível usar o Lazarus em alternativa ao Delphi para desenvolver aplicações comerciais?

Software envelhece?

Quando é que eu vou usar isso na minha vida?

Leitura recomendada

Criando uma aplicação em shell script integrada com o Interbase/Firebird

Case de Sucesso com Sistema de Gestão Hospitalar

Lazarus com Firebird e JVUIB

Acessando o Firebird que esta atras de um firewall

Interbase no Debian

Comentários

[1] Comentário enviado por cruzeirense em 20/07/2009 - 10:45h

Evaldo,

Parabéns pelo artigo.
Eu utilizo o Interbase com delphi 7 há alguns anos e sempre me atendeu bem.
A única deficiência que encontrei no banco é que ele utiliza um modo de transferência de dados que o torna muito lento ao rodar pela internet (Ex. Utilizando entre filial X Matriz).
Agora, os recursos citados acima são excelentes, mas devem ser sempre utilizados com cautela.
Quanto mais você se apegar aos recursos de uma ferramenta, mais dependente dela você fica.
Vamos supor que você crie uma aplicação toda baseada em procedimentos armazenados e gatilhos, se você futuramente precisar mudar de banco de dados aí fica muito complicado, pois cada banco de dados utiliza uma linguagem diferente (apenas em procedimentos armazenados e gatilhos, os comandos SQL comuns são padronizados!).

Abraços,

Renato

0 0

[2] Comentário enviado por evaldoavelar em 20/07/2009 - 11:26h

È isso mesmo Renato, o uso dos recursos torna maior a dependência com o banco de dados e deve ser bem planejado, mas como você citou ai, em aplicações rodando pela internet, esses recursos podem ajudar muito no tempo de resposta, deixando as aplicações mais agíeis.

0 0

[3] Comentário enviado por wryel em 23/07/2009 - 12:11h

Ótima base para banco de dados, algmas dúvidas que eu havia que iam alem de dmls, foram sanadas aqui, tranks for share :D

0 0

[4] Comentário enviado por albertoaalmeida em 01/07/2010 - 20:16h

Bom o artigo, visto que, a agilidade na internet é sempre muito importante. Porém fico com o Renato quanto mais recursos utilizamos de uma ferramenta, mais dependente ficamos da mesma.

Abraços..

Alberto Almeida
http://www.albertoalmeida.blogspot.com

0 0