Diversas formas de usar Stored Procedures com o .NET Framework
Neste artigo veremos qual é a importância das Stored Procedures nos BD relacionais, por que precisamos saber utilizá-las, e quais são as diversas formas de trabalhar com elas no .NET Framework e Visual Studio.
Stored Procedures
As diversas formas de usar Stored Procedures com o .NET Framework
“Você já notou que todas as letras da palavra database são digitadas com a mão esquerda? O padrão QWERTY para layout de teclados foi projetado, além de outras coisas, para facilitar o uso das duas mãos na digitação. Parece, entretanto, que escrever sobre databases não é apenas incomum, mas algo bem mais difícil do que parece.”
Esse ditado sobre databases é de um autor desconhecido, e foi retirado da segunda edição do livro Database Management Systems, da editora McGraw-Hill, escrito por Raghu Ramakrishnan e Johannes Gehrke.
Apesar da bizarra coincidência da palavra database estar posicionada do lado esquerdo do teclado, escrever sobre databases sempre foi algo complexo mesmo. E continua sendo, principalmente hoje em dia onde vivemos o dilema da Orientação a Objetos X Bancos de dados Relacionais.
Stored Procedure, como veremos em maiores detalhes, é um dos recursos que tornam os Bancos de Dados Relacionais ferramentas que vão além do simples 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
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. "
[...] continue lendo...
Artigos relacionados
-
Artigo
-
Artigo
-
Artigo
-
Artigo
-
Artigo