[firebase-br] RES: Views
Eduardo Bahiense
eduardo em icontroller.com.br
Sáb Jun 21 17:31:53 -03 2008
Magno Machado escreveu:
> Eu trabalho assim, não temos o menor interesse em multibanco. E o fato de
> colocar o maximo possivel no banco de dados torna algumas coisas mais
> faceis, pois toda a integridade, validações e etc vai estar centralizada.
Bem, integridade e validações concernetes à integridade são funções do
banco. Isso não se discute.
> Assim se por ventura for necessario o desenvolvimento de outro aplicativo
> cliente, ou se for necessario acessar diretamente a base de dados para
> alguma manutenção, a chance de alguem bagunçar os dados é bem menor.
O que quero dizer é que se você possui um servidor de aplicação, ou
camada do meio, muito do que se resolve via SP, especialmente o que diz
respeito a SPs selecionáveis, pode ser resolvido pelo servidor de
aplicação, que tem muito mais recursos de linguagem e de tomada de
decisão que o banco, e é de muito mais fácil manutenção.
Em uma arquitetura em camadas, seu servidor de aplicação pode estar
manuseando inúmeros bancos, assim, a centralização de alguns processos
nele (servidor de aplicação) evita que se altere metadata em diversos
bancos e caso de manutenção.
Digamos que eu tenha uma query que roda com nuita frequência em meu
sistema e quero otimizá-la ao máximo quanto à performance. Tenho duas
opções:
1. Construí-la dinamicamente
2. Criar uma SP selecionável com parâmetros
Então, testo a performance das duas opções, se não tenho vantagem
significativa criando mais um metadata no banco, prefiro deixar no
servidor de aplicação, pois, como já disse, estará mais centralizada que
se repetida nos diversos bancos utilizados pelo servidor e a manutenção
disso não envolve reiniciar o servidor de dados.
Observe que minha realidade é: Um servço rodando em datacenter, com
clientes em diversas cidades, acessando um único servidor. Distribuo
aplicativos "cliente". Toda a parte servidora, camada do meio e servidor
de dados está em um único datacenter. Não tenho que atualizar clientes
em nada que concerna a essas duas camadas.
Existem coisas que, preferencialmente, devem estar no banco, como
triggers, que são fantásticas devido sua natureza em cascata, SPs que
apoiam triggers, domains, que facilitam enormemente a manutença de
tabelas, e, claro, todo tipo de constraint. Mas no que se refere a
recuperação de dados, como as SPs selecionáveis e views, em uma
arquitetura em camadas, continuo defendendo sua colocação no código do
servidor de aplicação.
Naturalmente, isso vai da estrutura de cada um. Não percebo que a
cultura da arquitetura em camadas esteja bem consolidada. Vejo muita
gente usando um frame work n camadas, programando com cultura
cliente/servidor.
Por isso acho que esse tipo de discussão - onde ponho isso ou aquilo,
faço SP ou não - para que serve a tal da view, são de extrema relevância
e deveriam ser discutidas com bases mais técnicas que no âmbito da
preferência pessoal.
Agora, que seu sarcasmo foi desnecessário... ah! isso foi! (rsrsrs)
Grande abraço
Eduardo
Mais detalhes sobre a lista de discussão lista