[firebase-br] RES: Views

[Eduardo Bahiense]

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