Firebird, fazendo valer o lado do servidor


Autor/fonte: Evaldo Avelar Marques
E-mail/Url: http://www.vivaolinux.com.br/artigo/Firebird-fazendo-valer-o-lado-do-s...
Tags: [ firebird ]



Digg del.icio.us

Recursos

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.

Além do que, consultas enviadas pelos clientes precisam ser avaliadas, processadas para depois serem devolvidas, tempo precioso que podemos economizar utilizando alguns desses recursos do Firebird como Stored Procedures, Triggers, Views e Exceptions:

  • Stored Procedure: é um programa escrito numa linguagem própria para procedures e Triggers do Firebird que é armazenado como parte do banco de dados. Elas podem ser executadas pelar aplicação cliente ou por outras Stored Procedures ou mesmo Triggers. Bastante uteis para fazer cálculos e outras rotinas;
  • Triggers: são escritas da mesma forma que Stored Procedures. Elas são disparadas automaticamente quando há uma alteração em alguma tabela do banco de dados. Muito usadas para checar entradas de dados;
  • Views: é uma visão de alguma tabela, muita usada quando se precisa ocultar campos de usuários ou mesmo quando é preciso usar muitos subselects para gerar uma query ou para ajudar em querys complexas. A View também é armazenada como parte do banco de dados;
  • Exceptions: são exceções geradas quando há alguma anomalia ou quando o fluxo normal é interrompido.


Agora que já sabemos de alguns dos principais recursos que dispomos, vamos ver como podemos aplicá-los? Para isso vamos dar um exemplo simples de cada um.

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.

Triggers

Suponha que você precisa manter um histórico do funcionário cada vez que ele tiver um aumento, na sua aplicação, como ficaria?

Você enviaria duas Querys, uma atualizando o salário e outra o histórico:

UPDATE FUNCIONARIOS SET SALARIO= SALARIO +( (:PERCENT*100) / SALARIO ) WHERE ID = :ID ;
INSERT INTO HISTORICO (DATA,ID_FUNCIONARIO, SALARIO_ANTERIOR,NOVO_SALARIO) VALUES ( :DATA, :ID_FUNCIONARIO,:SALARIO_ANTERIOR,:NOVO_SALARIO);

Trabalhoso, não é?

A Trigger pode muito bem fazer isso por nós, vamos criar uma:

CREATE TRIGGER FUNCIONARIOS_BU0 FOR FUNCIONARIOS
ACTIVE BEFORE UPDATE POSITION 0
AS
BEGIN
  IF (OLD.SALARIO <> NEW.SALARIO) THEN  -- checa se houve alterações no salario
  BEGIN
    INSERT INTO HISTORICO  (DATA,ID_FUNCIONARIO, SALARIO_ANTERIOR,NOVO_SALARIO) VALUES ( CURRENT_DATE, NEW.ID,OLD.SALARIO,NEW.SALARIO); --atualiza o histórico
  END
END

Repare no "ACTIVE BEFORE UPDATE", ela será disparada antes de uma atualização da tabela FUNCIONARIOS. Ou seja, toda vez que executarmos a nossa Stored Procedure ela será acionada:

EXECUTE PROCEDURE DAR_AUMENTO(1,10) ;

Ao executar isso você já dá o aumento como também atualiza o histórico do funcionário e, o que é melhor, sem gerar tráfego pela rede!

João ganhou 10% de aumento e já atualizamos seu histórico na tabela Histórico:

ID_FUNCIONARIO   DATA        SALARIO_ANTERIOR   NOVO_SALARIO
1                16/7/2009   20                 70

Views

Bem, agora precisamos disponibilizar o nome, a data e quanto o funcionário recebeu de aumento. Vamos usar uma View para isso:

CREATE VIEW VIEW_AUMENTO(
    NOME,
    DATA,
    AUMENTO)
AS
SELECT NOME, DATA,   ( NOVO_SALARIO - SALARIO_ANTERIOR ) AS AUMENTO FROM HISTORICO H
LEFT JOIN FUNCIONARIOS ON ID = ID_FUNCIONARIO;

Agora uma consulta:

SELECT NOME, DATA, AUMENTO FROM VIEW_AUMENTO

Saída:

NOME    DATA        AUMENTO
José    16/7/2009   50
Maria   16/7/2009   22,22

Mais uma consulta com somente o nome das pessoas que tiveram aumento hoje:

SELECT NOME FROM VIEW_AUMENTO WHERE DATA = CURRENT_DATE

Saída:

NOME
José
Maria

Repare que a View nos permite fazer consultas como se fosse uma tabela normal e não precisamos ficar enviando Querys complexas que precisam ser preparadas e processadas todas as vezes, basta dar um select na View. A View pode ser usada para muitas outras coisas.

Agora pense numa aplicação pesada e robusta, com milhões de registros, usando esses recursos disponibilizados pelo Firebird. A sua aplicação ganhará muito mais agilidade deixando toda a parte pesada a cargo do servidor, sem falar no tráfego de rede que será muito reduzido.

Abaixo alguns links que você poderá usar para se aprofundar mais no assunto.

Links úteis:





Enviado por xKuRt em 21/07/2009 às 10:50


Itens relacionados

Instalando Firebird 2 com FreeAdhocUDF no Debian
Remoção de constraint no Firebird
Triggers no Firebird
Strings de conexão ao Firebird
O que são Generators no Firebird
Instalando o ibWebAdmin

Avaliação

Esta publicação ainda não foi avaliada!


Avaliar:


A avaliação de publicações é restrita a membros cadastrados e logados no nosso site.



Comentários

Este artigo ainda não foi comentado ou o(s) comentário(s) que foi(ram) enviado(s) a ele ainda não foi(ram) publicado(s).


Envio de comentário:




  

Terça, 29 de Julho de 2014




Top 5 membros

Últimos membros online

  • 1em 29/07 às 09:08
  • xKuRtem 27/07 às 15:13
  • JCanecaem 26/07 às 19:02

Últimos membros cadastrados



Capa do livro
Microsoft SQL Server 2012 Express: Guia Prático e Interativo


Capa do livro
Redes de Computadores - Versão Revisada e Atualizada


Capa do livro
Livro - Desenvolvendo para iPhone e iPad: Aprenda a desenvolver aplicativos utilizando iOS SDK





Hostnet

IMD