SQL Avançada Luídne Mota, 16 de março de 2012
Views Views ou simplesmente, Visões em banco de dados são tabelas virtuais criadas a partir de uma ou mais tabelas físicas de um banco de dados. Ela permite fazer consultas aos dados de maneira virtual, isto é, fazer consultas sem que sejam realmente nas tabelas físicas, isso ajuda na segurança de informações. Por exemplo: Podemos criar uma tabela que será usada para as consultas que serão feitas pelos alunos, alunos , desta maneira, podemos atribuir at ribuir à essa nova visão apenas os campos que lhe interessam como nome e sua média de uma disciplina. Isto aumenta a segurança, pois não terá como por algum método hacker obter os outros dados como a média de outros alunos, porque estão na tabela física.
Um uso que também podemos fazer com visões, acontece quando precisamos de alguns dados restritos numa tabela separada. Fazemos isto criando uma visão, ou mais se necessário, sem precisar duplicar os dados de uma tabela em outra no mesmo banco de dados. A sintaxe básica de uma visão é a seguinte: CREATE VIEW nome_da_visao AS SELECT t1. t1.campo1 campo1,, t2.campo2 t2.campo2 FROM tabela1 t1, tabela2 WHERE t1. t1.campo1 campo1<> <>12 12 AND t2.campo1 LIKE ‘nome%’;
É bom usarmos visões apenas quando se tratar de consultas, pois se pensarmos em fazer inserções, alterações ou exclusões podem tornar uma visão muito complexa. Em geral, uma visão suporta os mesmos comandos de uma tabela, afinal, visões também são tabelas, só que, virtuais.
Stored Procedure Stored Procedure, ou procedimento armazenado é uma coleção de comandos SQL que encapsula comandos para chamá-los como se fosse um comando só. É como de escrever um programa dentro do próprio servidor para ser executado dentro do próprio servidor. Serve para resolver tarefa que são executados com alta frequência. Tal caso, sem Stored Procedures, essas tarefas quando executadas demasiadamente no servidor de banco de dados lhe faz estar sobrecarregado ocasionando perda de desempenho. Por isso, o uso de Stored Procedure provê a melhora de performance, além de criar mecanismos de segurança na aplicação, etc. O objetivo da criação do Stored Procedure foi o equilíbrio da carga entre o servidor de aplicação e o servidor de bando de dados, ou seja, equilibrar a balança a qual os respectivos servidores são os pesos. Então, vamos iniciar a criação de um Stored Procedure... Sua sintaxe base é:
CREATE PROCEDURE nome() BEGIN comandos... END;
Por exemplo, podemos fazer o seguinte Stored Procedure: CREATE PROCEDURE todos_professores() BEGIN SELECT * FROM professor; END;
Para executá-lo basta chamá-lo pelo nome que demos a ele: CALL todos_professores(); Importante: Quando você usa “END;” para fechar o corpo do procedimento antes dele vem algum comando também terminado com “;” reconhecendo
como se ali fosse o final do procedimento. Por isso, antes de criamos nossa Stored Procedure vamos mudar o delimitador SQL padrão para “ // ”.
O comando para mudar é o seguinte:
Se tiver apenas um comando dentro do Stored Procedure não é necessário usar os delimitadores do corpo BEGIN e END. Como dito no começo desse artigo, Stored Procedure é como se fosse um programa, então, ele deve ter nenhum, um ou mais parâmetros. Veja como se cria um com parâmetro: CREATE PROCEDURE nome(variavel int) BEGIN SELECT * FROM professor WHERE idprofessor=variavel; END//
Até aqui fizemos um simples Stored Procedure. Vamos torná-lo mais próximo a um “programa” criando variáves e estruturas de controle como IF ELSE, WHILE. CREATE PROCEDURE nome(variavel int) BEGIN DECLARE var INT; SET var = variavel; IF(var > 0) THEN SELECT * FROM professor WHERE idprofessor=variavel; ELSE SELECT 0; END IF; END//
Agora com WHILE: CREATE PROCEDURE incrementa(parametro int) BEGIN WHILE paramentro >= 0 DO INSERT INTO outratabela(valor) VALUES(parametro); SET parametro = parametro + 1; END WHILE; END//
Agora chamamos a rotina: CALL incrementa(1);
Trigger Trigger, ou Gatilho, é um recurso usado em banco de dados SQL que visa execução de determinados procedimentos que são executados automaticamente quando é disparado algum evento em uma tabela ou uma view. Um problema: quando temos o conteúdo de uma tabela alterado, nesta alteração outros dados de outras tabelas podem estar relacionados e, consequentemente, alguns dados podem ficar sem nexo por isto. Para resolver este gargalo dentro do banco de dados usamos triggers. Solução: usamos uma trigger para que quando esta tabela for alterada possamos tomar alguma providência em relação à outra tabela. Triggers, por exemplo, podem ser usadas para gerar dados em uma tabela de
históricos do próprio bando de dados.
Outros exemplos que podemos citar do benefício são os seguinte:
Executar regras de negócio (exemplo: notificar um gerente de estoque quando o estoque de produtos estiver baixo); Replicar dados (exemplo: replicar dados em outro banco de dados como forma de monitoramento); Garantir desempenho (exemplo: atualizar o saldo de uma conta-corrente após uma transação, para consultas rápidas ao saldo).
Existem três tipos de trigger que podemos criar: 1. Para inserção de dados: INSERT; 2. Para exclusão de dados: DELETE; 3. Para atualização de dados: UPDATE; Sua sintaxe básica é: CREATE TRIGGER nome TIME EVENT ON tabela FOR EACH ROW instrucoes;
E para excluí-la: DROP TRIGGER nome;
Agora vamos criar um trigger básico: CREATE TRIGGER tg_cliente_cadastrar AFTER INSERT ON cliente FOR EACH ROW INSERT INTO auxiliar SET telefone = NEW.contato;
O NEW.nome é o campo nome da tabela cliente que será o novo dados inserido em todos registros da tabela auxiliar. Pode ser NEW ou OLD; O
TIME pode ser: AFTER ou BEFORE.
IMPORTANTE:
Não pode haver duas trigger numa dada tabela que tenha a mesma ação e evento. Por exemplo, você não pode ter dois BEFORE UPDATE para uma tabela. Mas você pode ter um BEFORE UPDATE e um BEFORE INSERT, ou um BEFORE UPDATE e um AFTER UPDATE.
Nota:
Atualmente, ações de chaves estrangeiras não ativam triggers. O EVENT pode ser: INSERT, DELETE ou UPDATE. Se você for usar mais instruções, por exemplo, INSERT, UPDATE e DELETE, você precisa delimitar o corpo das instruções com BEGIN e AND. E, ainda, delimitar a instrução SQL com outro delimitador que você mesmo especificar ao contrário do padrão que é “;”.
Por exemplo: DELIMITER // CREATE TRIGGER teste_trigger AFTER INSERT ON tabela1 FOR EACH ROW BEGIN INSERT INTO tabela2 SET campo1 = NEW.campo2; DELETE FROM tabela3 WHERE campo3 = NEW.campo1; UPDATE tabela4 SET campoA = campoB + 1 WHERE
Importante: Quando você usa “END;” para fechar o corpo do procedimento antes dele vem algum comando também terminado com “;” reconhecendo
como se ali fosse o final do procedimento. Por isso, antes de criamos nossa Stored Procedure vamos mudar o delimitador SQL padrão para “ // ”.
O comando para mudar é o seguinte: DELIMITER //
