[firebase-br] RES: Views

Magno Machado magnomp.gprs em gmail.com
Sáb Jun 21 09:33:40 -03 2008


>Sarcasmo desnecessário
Não acho.
Foi apenas uma continuação do raciocínio do proprio Eli para mostrar que as 
coisas não são bem assim como ele disse.

>Há outros que preferem o máximo no banco e o mínimo no aplicativo,
>herança talvez, da arquitetura cliente/servidor.
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. 
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.

"Eduardo Bahiense" 
<eduardo em icontroller.com.br> escreveu na 
mensagem news:g3hk74$nt7$1 em ger.gmane.org...
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
>


______________________________________________
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