Atenção: esse artigo tem um vídeo complementar. Clique e assista!

[lead]De que se trata o artigo:

Este artigo descreve a continuidade do projeto de um banco de dados para um sistema de locação de carros, onde são usados recursos de stored procedures, views e triggers no MySQL para simplificar as operações a serem realizadas por este sistema.

Para que serve:

Auxiliaria projetistas de banco de dados que possuem a necessidade de implementar bancos de dados, partindo de seus modelos físicos até a construção do banco de dados e seus objetos de apoio, como stored procedures, views e triggers.

Em que situação o tema é útil:

Stored procedures, views e triggers são recursos importantes a serem aplicados na implementação de um banco de dados, pois simplificam diversas operações a serem realizadas pelo banco de dados, assim como torna mais simples a codificação do sistema, definindo uma camada intermediária de controle entre o banco de dados físico e o código fonte da aplicação. [/lead]

Os SGBDs atuais oferecem diversos recursos que facilitam as tarefas de manipulação de dados e, consequentemente, o gerenciamento de um banco de dados. Dentre os principais recursos, que não são tão inovadores, mas que possuem uma importância gigantesca no trabalho de um DBA podemos citar as stored procedures, views e triggers.

Neste artigo, iremos dar continuidade ao desenvolvimento de uma aplicação responsável pelo gerenciamento de uma locadora de carros apresentada no artigo “Modelando um Sistema de Reserva de Carros”, publicado também nesta edição da SQL Magazine. Até o momento já possuímos suas tabelas e relacionamentos, nada mais que isso. Na continuidade deste projeto, iremos construir Stored Procedures (SPs), Views e Triggers que nos apóiam na realização das diversas operações realizadas por esta empresa.

[subtitulo]Stored Procedures [/subtitulo]

Uma stored procedure,ourotina,é simplesmente um repositório (container) para um conjunto de declarações SQL. Stored procedures podem conter declarações condicionais e processamento lógico que normalmente estaria indisponível em uma declaração SQL tradicional gerada dinamicamente.

Por exemplo, uma stored procedure pode contar comandos de loop ou condicionais, como do/while,if/then/else, dentre outros, permitindo a realização de operações mais complexas. Ou seja, uma SP funciona como um procedimento sobre o banco de dados, de forma similar aos procedimentos que usamos durante a codificação usando linguagens procedurais, tais como C ou Pascal.

Possuir códigos SQL em forma de stored procedures possibilita à aplicação minimizar a quantidade de código SQL que aparece no código fonte da aplicação e coloca estes códigos sob o controle da camada do banco de dados. Isso faz com que o projeto da aplicação fique mais claro e deixa as páginas de código fonte da aplicação livres de códigos SQL dinâmicos, que seriam desnecessários. Com isso, caso haja a necessidade de mudar alguma instrução em SQL, basta alterarmos o código da stored procedure, sem haver a necessidade de alterar o código fonte da aplicação e ter que recompilá-la.

No MySQL, stored procedures são rotinas criadas com as instruçõesCREATE PROCEDURE. Sua chamada ocorre através da instruçãoCALLe só pode passar valores de retorno usando variáveis de saída.

Atualmente o MySQL só preserva o contexto para o banco de dados padrão. Uma rotina herda o banco de dados padrão de quem a chama, assim geralmente as rotinas devem utilizar uma instruçãoUSE nome_bancodedados, ou então devemos especifique todas as tabelas com uma referência de banco de dados explicita, ex: ...

Quer ler esse conteúdo completo? Seja um assinante e descubra as vantagens.
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo