[firebase-br] Identificador para tabelas

[Edson T. Marques]

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