[firebase-br] Identificador para tabelas

Qua Maio 4 12:38:37 -03 2005

Só uma última coisa...

Se você achou as views lentas, com esse volumezinho minúsculo (5000
registros), imagine com 50.000.

E te digo, com o "computed by" em 1.000 registros a performance pode até ser
parecida, mas com 50.000 voce vai ver servidor trabalhando a 100% por um
boooooooom tempo, ou seja, muito mais lento do que as views.

Se você pode utilizar a SP, e fazer somente os joins que você precisa (ou
quando precisa), melhor. Aqui a performance melhora, e dependendo de como a
SP for escrita, melhora muito.... Mas seu problema é que as querys são
confusas (para o servidor) e muitas vezes você deve utilizar wheres que não
permitem índices. Quando sair o FB 2.0, será possivel criar índices (sem
contar a otimização destes) para UDFs e Campos Calculados (não estou falando
de computed by e sim de "expressões") aí o seu problema poderá ser
minimizado.

Quanto à view montar todo o seu resultset, isto pode ser verdade para o FB
1.0 em várias situações, mas é falso para o FB 1.5. Eles trabalharam muito
no otimizador em relação à elas.

Mas volto ao início de tudo. Entendo o seu problema (utilizar um banco
relacional mantendo características de um aplicativo DOS) mas não concordo
com a solução.

Trabalhamos com o desenvolvimento de sistemas contábeis, onde facilmente
existem 200 mil registros apenas na tabela de lançamentos nas bases de
nossos clientes. Fizemos testes com uma base de 2 Milhões de registros
(praticamente 900 MB). e o cadastro, alteração foram extremamente
satisfatórios (com tempo maior que com 200 mil, mas não proibitivo) e
selects (procuras) com respostas abaixo de 10 segundos.

Apenas um relatório do livro razão demoraria algo acima de 20 minutos, mas
como é utilizado raramente, seria completamente aceitável.

Se mantivéssemos o recurso que havia no nosso sistema DOS de abrir a tela
com o último registro lançado no Exercício (select max....) o sistema
demoraria quase 30 segundos para abrir a tela. então, esquecemos isso, e a
tela abre entre 1 ou 4 segundos (dependendo do terminal).

às vezes vale a pena sacrificar algumas frescuras, mesmo perdendo um cliente
ou outro do que correr o risco de perder "todos" por culpa da lerdeza do
sistema... Ou seja, hábitos vem e vão, a paciência, não, ela só diminui....

[s]

======================
Eduardo Jedliczka
Apucarana - Paraná
======================

----- Original Message -----
From: "Edson T. Marques" <marques em oriontec.com.br>
To: "FireBase" <lista em firebase.com.br>
Sent: Wednesday, May 04, 2005 9:24 AM
Subject: Re: [firebase-br] Identificador para tabelas

> Opaaaa...!
>
> Agora sim a discução ficou boa e estamos nos entendendo!
> Fiquei muito satisfeito com as respostas de vocês! Muito agradecido! Já
> dá para tomar uma decisão e isso veio em ótima hora. Estou trabalhando
> com esse banco já há uns 2 anos e agora pintou a oportunidade de estar
> fazendo umas correções. Esses campos "computed" sempre me deixavam com
> uma enorme interrogação quando os via no script!
>
> Quanto `a xingarem minha doce mãezinha (falando nisso domingo é dia
> deleas e um feliz dia das mães para todos) infelizmente isso já vem
> acontecendo, oque me levou a ficar meio inquieto e um tanto estressado.
>
> Quanto à view nós já tentamos fazer isso aqui no banco mas foi do lado
> da tabela de Pessoas (não da de Produto). A tabela de Pessoas do nosso
> banco de dados se relaciona, também, com uma porrada de outras tabelas,
> os dados foram quebrados em várias tabelas, assim temos, por exemplo,
> uma tabela de pessoas se relaconando com uma tabela para dados de Pessoa
> Física, Juridica, Endereços, Telefones... e por aí vai. A solução que
> demos foi justamente fazer uma grande view de Pessoas que juntasse todas
> essas informações em uma única estrutura.
>
> Aí veio o efeito: quando as tabelas foram crescendo fomos tendo quedas
> drásticas de performance. E isso era no FB 1.0. Chegavamos ao ponto de
> para trazer 5000 pessoas numa consulta (simples tipo: select * from
> viewPessoas where DTCadastro <= '28-02-2000') tinhamos que esperar cerca
> de 25 segundos para o retorno (isso aqui na empresa, onde todos os
> equipamentos são ótimos - nos clientes gastava minutos...). Os clientes
> começaram a atirar coisas das mais estranhas na gente (!) (se é que
> vocês me entendem). Foi quando tivemos a idéa de usarmos stored
> procedure para retornar esses dados. Como podemos passar parâmetros para
> o SP podiamos fazer as consultas mais específicas. Demos uma reciclada
> nas nossas idéas (melhoramos as consultas, os índices e tudo mais) e
> para compensar ainda saiu o FB 1.5 que melhorou muito a performance com
> PLANS mais inteligentes... Aí foi que a coisa ficou suportável.
>
> Ainda sobre view, a informação que temos é que, em uma view,  se você
> faz um select com where, ele vai ser "select sobre o result set da view"
> e isso seria mais lento do que fazer a consulta direto com os joins e
> com o where apropriado. Principalmente se a view for muito cheia de
> joins (são left joins porque é necessário retornar todos os Produtos
> mais os campos das tabelas com as quais Produtos se relaciona)). Essa
> informação está errada?
>
> Oque eu estou tentando dizer é que no nosso sistema eu TENHO que ter o
> controle sobre a consulta. Isso é necessário porque criamos interfaces
> que permitem ao usuário manipular (amigavelmente) as cláusulas "where" e
> "order by" dessas consultas, justamente para que eles possam controlar
> oque eles querem ver na tela. Dessa forma, se considerarem o exemplo do
> produtos, quando o usuário entra na interface de cadastro de produtos,
> por exemplo, a primeira coisa que ele tem é uma interface com um grid
> que mostra para ele todos os produtos do cadastro (e consequentemente os
> dados das demais tabelas (isso atualmente sendo feito com campos
> computed)). Foi necessário fazer isso (essa interface com consulta
> trazendo tudo) porque enfrentamos uma resistência muito grande dos
> usuário do nosso antigo sistema feito em clipper. Eles ameçavam não
> renovar com a gente se a interface fosse muito diferente. A partir daí
> ele (o usuário) pode livremente cadastrar um novo produto, alterar um
> existente, apagar outro, pode fazer um filtro, pode ordenar por qualquer
> coluna, fazer buscas, organizar as colunas do grid e os dados e depois
> tirar um relatório disso, e vai por aí a fora.... O filtro e a ordenação
> são feitas diretamente alterando o comando SQL (nas clausulas where e/ou
> order by) e refazendo a consulta. Já a busca nós implementamos
> diferente, trabalhamos direto sobre o dataset. Usamos os componetes IBX.
> o DBgrid fomos nós que implementamos.
>
> É por isso que com a view o negócio complica!
>
> Pessoal, mais uma vêz muito obrigado!
> Eduardo, valeu muito cara!
>
> []'s
> Edson
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas:
http://search.gmane.org/search.php?group=firebase