Este é um post disponível para assinantes MVP
dê seu feedback
post favorito
Dúvidas SQL Magazine 14
Dúvidas da Revista SQL Magazine - Edição 14.
Clique aqui para ler todos os artigos desta edição
Dúvidas
Dúvida 1
Resposta
Olá André!
Quanto à sua pergunta: stored procedures são sempre bem-vindas, pois economizam largura de banda. Imagine enviar um batch com 500 linhas para ser executado no servidor. Agora troque as 500 linhas por uma única linha de chamada para a stored procedure. O que é mais rápido? Outra grande vantagem é que você não precisa ficar abrindo os fontes de seus programas para alterar o código, fora o fato da stored procedure ser muito mais maleável: se houver alguma alteração no negócio, você altera somente a stored procedures, sem a necessidade de abrir fontes e recompilar sua aplicação!
Mas a questão básica dessa discussão é a seguinte: em que camada você irá deixar as regras do seu negócio: na de aplicação ou banco? Tudo tem caminhado para que as regras de negócio fiquem no banco, pois além dos requisitos de segurança, deixam as aplicações mais eficientes e são mais fáceis de implementar, mais simples de administrar e convivem melhor com alterações.
Quanto justificar a criação de views por questões de segurança, acho desnecessário. Views são utilizadas para substituir select's complexos (exceção seja feita às indexed views, que materializam o select na forma de páginas de dados por questões de otimização).
Quanto aos locks, eles existem em views, stored procedures, batches. Na edição de número 5 da SQL Magazine, escrevi uma matéria exclusiva sobre como otimizar locks. Você chegou a dar uma lida? Se você não possui esse exemplar, escreva para a SQL Magazine solicitando o seu.
Um grande abraço,
Paulo Ribeiro
Pergunta
Caro Professor,
Parabéns pelos artigos publicados na SQL Magazine! São de grande valia para os profissionais de software. Gostaria de saber sua opinião quanto a um assunto: nas empresas, parece que há duas linhas de pensamento quando o assunto é stored procedure, trigger e view. Uma delas defende o uso desses recursos para algumas rotinas mais pesadas. A outra segue a linha de que tudo deve ser acessado através de stored procedures e view, tanto na leitura quanto na escrita (inclusão, alteração e exclusão). Não se pode acessar as tabelas diretamente, por motivos de segurança e de "lock". O que você acha sobre isso? Há algum material (livro ou site) que aborde essa situação?
Abraços e obrigado,
André
Dúvida 2
Resposta
Oi Renato,
Sim, a utilização de árvore binária, em determinados casos, pode realmente gerar uma tabela de índices maior que a de dados. Para esses casos, a utilização de índices bitmap passa a trazer maiores benefícios.
Os índices são ponteiros para linhas da tabela organizados de forma a melhorar o desempenho para seleção registros. No caso dos índices tradicionais, esses valores são armazenados em uma lista de rowids para cada chave correspondente, ou seja, é criada uma nova tabela (tabela de índices) contendo o valor da chave e o rowid correspondente. Já um índice bitmap trabalha criando um mapa de bits para cada valor ao invés da lista das rowids. Cada bit do mapa corresponde a um possível rowid. Se o bit é selecionado, significa que a linha com o valor correspondente contém o valor da chave.
Uma função de mapeamento converte a posição do bit no valor do rowid, mantendo a mesma funcionalidade dos índices tradicionais. Porém, em casos em que a seletividade é baixa, como em uma coluna “sexo” (valores “F” ou “M”), os índices bitmap trarão um enorme ganho de espaço de armazenamento, uma vez que não será necessário armazenar o valor da coluna e seu respectivo rowid. Vejamos como exemplo a tabela abaixo:
|
COD_CLI |
EST_CIVIL |
REGIAO |
GENERO |
NIVEL_RENDA |
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
0 COMENTÁRIO
0
0
