[firebase-br] RES: Views

Eduardo Bahiense eduardo em icontroller.com.br
Sex Jun 20 22:06:41 -03 2008


Sarcasmo desnecessário

Existe uma grande discussão de onde se colocam as coisas.
Eu, por exemplo, em um ambiente em 3 camadas, defendo a corrente que 
acha que é melhor ter o mínimo no banco e o máximo no servidor de 
aplicação, que lida com os result sets e tem oportunidade de 
processá-los antes de enviar ao cliente, pelos motivos abaixo:
1. As possibilidades de linguagem são mais amplas que as que o banco oferece
2. Facilita o desenvolvimento multi-banco
3. Facilita a depuração de problemas, pois a maioria do código está no 
mesmo lugar
4. Não deixa propriedade intelectual, código de decisão, na mão de 
terceiros que possam se apropriar do banco

Há outros que preferem o máximo no banco e o mínimo no aplicativo, 
herança talvez, da arquitetura cliente/servidor.

No caso das Views, teriam muita utilidade se pudessem ser indexadas, 
otimizando seus WHEREs, podendo substituir SPs selecionáveis. Acredito 
que com o advento das SPs selecionáveis e as melhorias em PSQL dos 
bancos, as Views estão se tornando cada vez mais recursos obsoletos nos 
bancos.

Esses dias, por me sentir culpado por não abusar de SPs, como muitos na 
lista advogam, sabendo que SPs são pré-compiladas e, em tese, 
resultariam melhor performance pela redução do tempo de "prepare", 
resolvi fazer alguns testes com consultas complexas do sistema 
transformando-as, de queries dinâmicas em SPs. Qual minha surpresa, que 
não obtive ganho algum na performance, algumas ficaram ligeiramente mais 
  lentas em SPs.

Conclui com esse experimento, que ainda é melhor, no meu caso, que o 
servidor de aplicação lide com isso, pois atualizar metadata em banco de 
dados é muito mais custoso que editar algumas linhas de código no 
servidor de aplicação.

Vejo muita discussão aqui na lista sobre capacidade do FB, sobre seu 
comportamento na internet.

Hoje temos nosso serviço rodando em datacenter 24/7, 3400 usuários (não 
simultâneos), 3 BD's de aproximadamente 1GB cada, em dual core 1GB de 
RAM, rodando Debian, com FB 2.0 Super Server e o nosso FB velho de 
guerra dá show! Estabilidade à toda prova, nada de perda de dados, nada 
de reiniciar. Em um ano e meio de operação, apenas uma vez tivemos o 
famigerado 99% de uso da CPU, mas não conseguimos determinar a razão.

Sendo o Software como serviço, hospedado em datacenters, uma forte 
tendência. Acho que deveríamos começar a estudar com carinho arquitetura 
em camadas e repensar nossa cultura cliente/servidor.

Abraço a todos


Eduardo


Isto porque
Magno Machado escreveu:
> Nesse caso, podemos eliminar do banco de dados recursos como joins, funções, 
> integridade, etc, afinal, podemos fazer tudo dentro da aplicação.
> 
> "Eli" <eliflavio em gmail.com> escreveu na 
> mensagem news:g3h5mj$hkk$1 em ger.gmane.org...
> Mas neste exemplo que você deu, porque não criar uma função na linguagem
> de programação que monta este SELECT? Sem contar que é muito mais fácil
> administrar um código dentro da linguagem do que no banco de dados.
> 
> Eli
> 
> 
> Forrest® escreveu:
>> Tudo depende do ponto de vista Eder, eu também nunca tinha visto uma real 
>> utilização de uma view
>> até o Jeferson Oliveira que por sinal está meio sumido daqui. vamos dizer 
>> que você tem uma tabela
>> de contas a receber e outra de contas recebidas e você quer trazer em um 
>> select alguns campos tanto
>> da tabela a receber como da recebida. Bom pode ser feito um select, sim 
>> pode mas aí em qualquer
>> lugar que você for usar tem que montar todo o select novamente enviar para 
>> o BD e aguardar a
>> resposta. Não seria muito melhor você ter essa view no BD e sempre que 
>> precisar só fazer um SELECT
>> * FROM NOMEVIEW. Fica muito mais prático sem contar que no select da view 
>> vc pode incluir
>> parametros ainda.
>>
>> T++++++++++++++
> 
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: 
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> 
> 
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> 





Mais detalhes sobre a lista de discussão lista