Esse artigo faz parte da revista .NET Magazine edição 62. Clique aqui para ler todos os artigos desta edição

les armazenamento de dados. E assim como os databases, é igualmente difícil escrever sobre Stored Procedures.

Neste artigo veremos qual é a sua importância nos bancos de dados relacionais, por que nós desenvolvedores precisamos saber utilizá-las, e quais são as diversas formas de trabalhar com elas no .NET Framework e Visual Studio.

O que é uma Stored Procedure?

A definição mais comum do termo diz que: Stored Procedure, ou no português: Procedimento Armazenado, é um conjunto de comandos SQL que juntos formam uma rotina ou sub-rotina. Própria dos databases relacionais, a idéia é que as Stored Procedures fiquem armazenadas junto com os dados, dentro do mesmo database.

Em termos práticos isso significa que ao executarmos essas rotinas, temos dois benefícios significativos: a execução dos comandos é mais rápida já que eles não precisaram ser transferidos pela rede, a única coisa que fazemos é indicar qual Stored Procedure queremos executar. Seu uso torna a aplicação mais segura, já que há uma chance muito menor dos comandos SQL serem intencionalmente modificados no caminho que percorreriam entre o Cliente e o Servidor em casos onde não se utiliza Stored Procedures.

Para os íntimos, as Stored Procedures também são conhecidas como proc, sproc, StoProc, PA Procedimento Armazenado ou SP. Neste artigo, toda vez que você ver a sigla SP saberá que estamos falando das Stored Procedures.

Elas foram criadas como recursos adicionais dos Bancos de Dados Relacionais. Esses recursos que vão além da capacidade nata de armazenamento de dados, tornaram os Databases ferramentas muito mais robustas.

       

Nota do DevMan

Um Banco de Dados Relacional é um banco de dados que segue o Modelo Relacional.

De forma mais detalhada, um Banco de Dados Relacional é um conceito abstrato que define maneiras de armazenar, manipular e recuperar dados estruturados unicamente na forma de tabelas, construindo um banco de dados.

O termo também é aplicável aos próprios dados, quando organizados dessa forma, ou a um Sistema Gerenciador de Banco de Dados Relacional (SGBDR) – do inglês Relational database management system (RDBMS) – um programa de computador que implementa a abstração.

Os Bancos de dados relacionais (BDR) surgiram em meados da década de 1970. Porém, apenas alguns anos mais tarde as empresas passaram a utilizá-los no lugar de arquivos planos (do inglês flat file), bancos de dados hierárquicos e em rede.

As 12 regras

Em 1985, Edgar Frank Codd, criador do modelo relacional, publicou um artigo onde definia 12 regras para que um Sistema Gerenciador de Banco de Dados (SGBD) fosse considerado relacional:

1. Regra Fundamental: Um SGBD relacional deve gerenciar seus dados usando apenas suas capacidades relacionais.

2. Regra da informação: Toda informação deve ser representada de uma única forma, como dados em uma tabela.

3. Regra da garantia de acesso: Todo dado (valor atômico) pode ser acessado logicamente (e unicamente) usando o nome da tabela, o valor da chave primária da linha e o nome da coluna.

4. Tratamento sistemático de valores nulos: Os valores nulos (diferente do zero, da string vazia, da string de caracteres em brancos e outros valores não nulos) existem para representar dados não existentes de forma sistemática e independente do tipo de dado.

5. Catálogo dinâmico on-line baseado no modelo relacional: A descrição do banco de dados é representada no nível lógico como dados ordinários (isso é, em tabelas), permitindo que usuários autorizados apliquem as mesmas formas de manipular dados aplicada aos dados comuns ao consultá-las.

6. Regra da sub-linguagem compreensiva: Um sistema relacional pode suportar várias linguagens e formas de uso, porém deve possuir ao menos uma linguagem com sintaxe bem definida e expressa por cadeia de caracteres e com habilidade de apoiar a definição de dados, a definição de visões, a manipulação de dados, as restrições de integridade, a autorização e a fronteira de transações.

7. Regra da atualização de visões: Toda visão que for teoricamente atualizável será também atualizável pelo sistema.

8. Inserção, atualização e eliminação de alto nível: A capacidade de manipular a relação base ou relações derivadas como um operador único não se aplica apenas a recuperação de dados, mas também a inserção, alteração e eliminação de dados.

9. Independência dos dados físicos:

- Programas de aplicação ou atividades de terminal permanecem logicamente inalteradas quaisquer que sejam as modificações na representação de armazenagem ou métodos de acesso internos.

- Independência lógica de dados.

- Programas de aplicação ou atividades de terminal permanecem logicamente inalteradas quaisquer que sejam as mudanças de informação que permitam teoricamente a não alteração das tabelas base.

10. Independência de integridade: As relações de integridade específicas de um banco de dados relacional devem ser definidas em uma sub-linguagem de dados e armazenadas no catálogo (e não em programas).

11. Independência de distribuição:

A linguagem de manipulação de dados deve possibilitar que as aplicações permaneçam inalteradas estejam os dados centralizados ou distribuídos fisicamente.

12. Regra da Não-subversão:

Se o sistema relacional possui uma linguagem de baixo nível (um registro por vez), não deve ser possível subverter ou ignorar as regras de integridade e restrições definidas no alto nível (muitos registros por vez).

Definição retirada da Wikipédia

O que devemos colocar em uma Stored Procedure?

Qualquer comando SQL pode ser armazenado em uma Stored Procedure. Ela funciona como uma rotina ou função. Pode ser criada para receber parâmetros e devolver um retorno, que pode ser um conjunto de registros ou um simples valor.

Em tese, você pode utilizá-las para realizar qualquer operação de input ou output no database, e isso inclui desde as operações CRUD básicas, Insert, Update, Delete e Select, até operações mais elaboradas que envolvam parte da lógica da aplicação. Dentro de Stored Procedures podemos incluir estruturas lógicas compatíveis com a linguagem SQL, como: IF, WHILE, LOOP, REPEAT, CASE.

E é aí que está a maior polêmica em torno de seu uso. Até que ponto a lógica da sua aplicação deve ficar armazenada no seu banco de dados? Devemos manter a lógica em nosso código gerenciado, onde temos os recursos da orientação a objetos, ou devemos colocar nossa lógica em Stored Procedures, para ganhar em performance e compatibilidade com o banco?

Tudo depende do seu projeto, das especificações e requisitos que sua aplicação vai ter. Você vai encontrar casos onde a própria cultura da empresa vai lhe dar essa resposta.

Inevitavelmente, num grau maior ou menor você vai se deparar com um cenário híbrido. É praticamente impossível manter 100% da sua lógica em Stored Procedures, principalmente porque parte da lógica da sua aplicação vai depender de recursos que você não pode acessar através da linguagem SQL.

Ultimamente a prática mais comum para um ambiente onde temos uma linguagem orientada a objetos acessando um banco de dados relacional, é focar o uso das Stored Procedures nas operações CRUD e em operações de pesquisa mais avançadas, onde a performance é importante. Os exemplos que veremos nos próximos capítulos deste artigo, serão focados neste cenário.

       

Nota do DevMan

CRUD é o acrônimo da expressão em língua Inglesa Create, Retrieve, Update e Delete, usada para definir quatro operações básicas usadas em bancos de dados relacionais (RDBMS) ou em interface para usuários para criação, consulta, atualização e destruição de dados.

Outros acrônimos podem ser usados para definir as mesmas operações:

ABCD: Add, Browse, Change e Delete

BREAD: Browse, Read, Edit, Add e Delete

VADE(R): View, Add, Delete, Edit (e Restore, para sistemas com processos transacionais)

...

Quer ler esse conteúdo completo? Tenha acesso completo