[lead]De que se trata o artigo:

O artigo apresenta as System Stored Procedures e discute como podemos utilizá-las em nosso dia a dia.

Para que serve:

Demostrações práticas de como podemos nos aproveitar dos recursos das System Stored Procedures para executar tarefas rotineiras tais como verificar as características de objetos; dos bancos de dados; listar o códigos de stored procedures, views e functions; verificar a dependência dos objetos do banco de dados.

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

As System Stored Procedures nos possibilitam tirar vantagem de várias rotinas prontas e testadas que nos ajudam em diversas tarefas diárias, como por exemplo verificar tamanho do banco de dados, ver a estrutura de tabelas, conhecer a assinatura e o conteúdo de stored procedures, dentre outras.[/lead]

Se formos olhar para trás, mais ou menos 10 anos, vamos nos lembrar como eram os bancos de dados. Um pequeno conjunto de arquivos DBF agrupados em um diretório era mais do que suficiente para controlar as tarefas básicas de uma empresa. Os sistemas, em sua grande maioria, também eram bem mais simples, e normalmente não ousavam muito em seus objetivos: controles de estoque, emissão de notas, contas a pagar e a receber. As integrações entre os bancos de dados não eram muito comuns, e a troca de informações quase sempre limitada a envio de arquivos TXT.

O acelerado desenvolvimento da tecnologia vem aumentando a dependência da sociedade em aplicações. Hoje em dia, é muito comum em uma mesma empresa encontrarmos vários servidores (físicos ou virtualizados), inúmeros bancos de dados e SGBDs diferentes, uma grande quantidade de aplicativos desenvolvidos em linguagens diferentes; e toda essa diversidade se integra de uma maneira ou de outra, formando uma grande e complexa teia de informações que mantém o organismo corporativo funcionando.

O profissional responsável pelo banco de dados, que no passado precisava apenas fazer backup dos dados, se depara com um número enorme de procedimentos de manutenção, backup, avaliação de performance e de consultas, mineração de dados, dentre outros. Seu tempo é cada vez mais escasso e sua responsabilidade cada vez maior. Para contornar esse problema, precisamos conhecer todo o potencial da ferramenta que possuímos em mãos e nos aproveitar de todas as suas qualidades.

Por exemplo, quem nunca teve que responder a famosa pergunta: “Qual o tamanho desse banco de dados? E qual sua previsão de crescimento?” ou “E essa tabela de histórico? Qual o tamanho que ela ocupa? Podemos apagar os registros do passado?” ou ainda quando estamos dando consultoria em um novo cliente ou mesmo mudando de empresa e ainda não conhecemos bem a estrutura do banco de dados, como podemos descobrir qual é o relacionamento de determinada tabela. Para essas e outras situações, podemos nos aproveitar das System Stored Procedures oferecidas pelo SQL e reduzir e muito nosso trabalho. Baseado neste cenário, nosso artigo vem falar um pouco sobre as System Stored Procedures, que com certeza podem nos ajudar em várias dessas rotinas diárias.

[subtitulo]Criando o ambiente[/subtitulo]

Para os exemplos desse artigo, estaremos utilizando como SGBD o SQL Server 2005 Express, além do SQL Server Management Studio Express como ferramenta de front-end para gerenciamento dos bancos de dados no SQL Server. Os dois são gratuitos e podem ser obtidos no endereço constante na seção de Links ao fim do artigo.

Iremos assumir que a plataforma SQL Server já está instalada e funcionando corretamente. Com isso, o próximo passo será criar o banco de dados que iremos utilizar na construção de nossos exemplos. Chamaremos este banco de dados de SQLMAG_SSP, e devemos criar sua estrutura conforme o diagrama da Figura 1.

Figura 1. Estrutura do banco de dados SQLMAG_ SSP de exemplo

O script para criação do banco de dados SQLMAG_SSP, suas tabelas, alguns registros de teste e a criação de uma stored procedure que irá cuidar de inserir registros na tabela de técnicos, está apresentado na Listagem 1.

Esse banco de dados serve para controlar a data e a temperatura obtida por cada técnico nas aferições realizadas nos instrumentos de uma grande fábrica de peças de metal.

A tabela “Instrumentos” armazena o maquinário que deverá ter sua temperatura aferida rotineiramente. A coluna InstrumentoId é uma coluna do tipo inteiro, incremental e é a chave primária da tabela. Já a coluna Descricao deve armazenar o nome dado ao instrumento.

Os técnicos responsáveis pelas aferições serão registrados na tabela “Tecnicos”. Sua chave primária é a coluna TecnicoId, que é um inteiro incremental.

Por fim, as aferições realizadas pelos técnicos serão registradas na tabela “Afericoes”. A coluna DataAfericao armazena a data e a hora da aferição. A coluna Temperatura registra a temperatura em graus Celcius registrada no instrumento. A coluna IntrumentoId é do tipo inteiro e não pode conter valores nulos (uma aferição sempre deve ser realizada por um instrumento), e ela indica o instrumento usado para realizar tal aferição, representando assim o relacionamento de 1:N entre a tabela “Instrumentos”e “Afericoes”, onde para cada aferição apenas 1 instrumento pode ser utilizado, porém um instrumento pode ser utilizado em inúmeras aferições. Por fim, a coluna ...

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