[firebase-br] Identificador para tabelas

Francisco Thiago jeandeadlucky em yahoo.com.br
Ter Maio 3 18:59:40 -03 2005 

Neste caso, as soluções 1 e 2 seriam as melhores... Eu uso algo assim. Daí o 
kra pode escolher qqr campo e fazer qqr comparação (só não dá pra fazer like 
em campo numérico :D).

O Computed by - embora eu nunca tenha mexido com eles por enquanto (evito ao 
máximo) - segundo o que o Eduardo falou, seriam realmente inviável.


Dá uma pensada colega.. esquece esse computed ae :D

Valew Eduardo!


Francisco Thiago de Almeida
Enter&Plug Informática
Divisão: Desenvolvimento e Banco de dados
MSN: thiago em enterplug.com.br
Skype: enterplug_thiago
----- Original Message ----- 
From: "Eduardo Jedliczka" <edujed em gmail.com>
To: "FireBase" <lista em firebase.com.br>
Sent: Tuesday, May 03, 2005 6:49 PM
Subject: Re: [firebase-br] Identificador para tabelas


> Francisco,
>
> Não creio que ele esteja falando em "alterar" as informações, imagino que
> queira apenas consultar. Mas sim, ele tem uma "super-consulta"
>
> Pelo que entendi, é uma tabela com 70 campos e 10 junções.
>
> Sinceramente, acho que se o sistema dele crescer e manter a estrutura com
> Computed By, os clientes vão chingar a mãe dele numa taxa de crescimento
> geométrica.
>
> A maior vantagem de utilizar Joins é que o banco trabalha menos (consome
> menos memória, faz menos acesso à disco, e utiliza drasticamente menos o
> analizador léxico), o que resulta em melhor performance como um todo.
>
> Se ele não pode trabalhar com views, até é compreensível, há muitos
> componentes que dão pau com views. Mas uma Query bem montada com 7 ou 8
> junções, que tragam apenas os registros que se precisa, é muito rápido. O
> problema é quando surgem os "full outer joins" ou os "left Joins com Right
> Joins" aí o banco chora mesmo...
>
> E apenas uma última pergunta ao Edson, se o componente escreve a Where, 
> como
> ele faz para filtrar os Computed By ???
>
> Se não souber eu respondo. Full table Scan...  ou seja, varre a tabela 
> pai,
> resolve o campo calculado linha a linha ( se tiver 100 mil registros, ele
> buscará o índice 100 mil vezes e se não tiver índice para este campo, fará
> um full table scan na tabela filha 100 mil vezes.) e retorna apenas o que
> cumprir a condição. ( ou seja 100 mil registros da tabela pai 
> "multiplicado"
> pelos registros da tabela filha)
>
> Se for através de um Join, o otimizador fará apenas uma busca entre 
> chaves.
> o ganho de desempenho é absurdo!
>
> [s]
>
> ======================
> Eduardo Jedliczka
> Apucarana - Paraná
> ======================
> ----- Original Message -----
> From: "Francisco Thiago" <jeandeadlucky em yahoo.com.br>
> To: "FireBase" <lista em firebase.com.br>
> Sent: Tuesday, May 03, 2005 6:20 PM
> Subject: Re: [firebase-br] Identificador para tabelas
>
>
>> kra, deixa eu ver se entendi.
>>
>> Você quer uma espécie de super consulta, onde na tabela de pedido, se o
>> usuário digitar o nome do Cliente, esta consulta traga todos os cliente
>> certo? E para piorar a situação, você ainda quer que o kra altere esses
>> dados?
>>
>> Você pode fazer o seguinte:
>>
>> 1º
>>
>> Monte uma tela de consulta e faça o select utilizando joins.
>> Ae quando o usuario escolher, por exemplo, o nome do cliente, ele traga 
>> os
>> pedidos do cliente
>>
>> Select Pedido.NumPedido
>>      , Clientes.NomeCliente
>> from Pedido
>>   join Clientes on Clientes.Codigo = Pedido.CodigoClientes
>> where
>>   Clientes.NomeCliente = 'José das Cucuias'
>>
>> Funciona do jeito que vc qr.
>>
>> 2º
>> O mesmo esquema acima, só que depois vc devolve apenas a chave do Pedido
>> para uma outra consulta e traz os dados do pedido tranquilo... e pode
> editar
>> e tudo... Daí sua tela de pesquisa ficaria realmente genérica.
>>
>> 3º (Caso esteja utilizando ClientDataSet)
>> Cria uma view com os dados necessário, Chama ela pelo CDS e no Evento
>> OnGetTable coloca o nome da tabela. Não se esqueça que desta forma você
>> precisa trazer na view os nomes exatos dos campos a serem atualizados e
>> ainda por cima desmarcar para alteraçãos os campos inalteráveis (nome do
>> cliente por exemplo). NUNCA TENTEI ISSO....
>>
>> Caso o problema seja filtros e ordenações por colunas, você pode usar
>> índices automáticos e campos de filtros. Com o CDS é muito fácil fazer
> isso.
>> Dessa forma você já economiza alguns select no banco... já que para
>> reordenar uma coluna, vc teria que requisitar os mesmos campos ao BD.
>>
>> Espero ter entendido a sua questão e ter ajudado vc um pouquinho
>>
>> []'s e boa sorte
>>
>> Francisco Thiago de Almeida
>> Enter&Plug Informática
>> Divisão: Desenvolvimento e Banco de dados
>> MSN: thiago em enterplug.com.br
>> Skype: enterplug_thiago
>>
>>
>> ----- Original Message -----
>> From: "Edson T. Marques" <marques em oriontec.com.br>
>> To: "FireBase" <lista em firebase.com.br>
>> Sent: Tuesday, May 03, 2005 5:42 PM
>> Subject: Re: [firebase-br] Identificador para tabelas
>>
>>
>> >
>> > Infelizmente não posso usar view.
>> > Nós temos um componente, feito em delphi, que permite fazer a
> manipulação
>> > das consultas que são exibidas na tela para o usuário. Com este
> componente
>> > nós implementamos funcionalidades muito importantes para o nosso
> sistema.
>> > Uma delas é, por exemplo, se o usuário vê na tela o Grid de produtos
>> > cadastrados ele poderá fazer filtros da maneira que ele quizer, em
>> > qualquer coluna, que os filtros (tem uma interface apropriada para 
>> > isso)
>> > são transformados em SQL e incorporados na clausula where da consulta
> que
>> > retorna oque ele está vendo.
>> >
>> > Se eu criar uma view no banco de dados para retornar esses dados, além
> de
>> > eu não me livrar dos joins (porque o select da view também vai ter que
> ter
>> > as junções), o esquema do componente vai fazer selects sobre result set
> da
>> > view, bom...  aí é que a vaca vai pro brejo pra valer!
>> >
>> > Eu preciso é de uma sentença sobre essa questão.
>> > Na sua opinião oque que é menos pior os campos calculados ou os joins?
>> >
>> > [s]
>> > Edson.
>> >
>> > Eduardo Jedliczka escreveu:
>> >
>> >>Edson,
>> >>
>> >>Para o seu caso, a melhor solução seria criar uma VIEW.  - Recomendo a
>> >>leitura dos PDFs do Interbase 6 sobre Views e Joins.
>> >>
>> >>Dependendo do seu componente de acesso, poderia gravar os campos na
> tabela
>> >>real e consultar pela view, em outros casos, poderia criar algumas
>> >>Triggers
>> >>na view para realizar o insert, delete e update...
>> >>
>> >>Posso dar mais detalhes à noite...
>> >>
>> >>[s]
>> >>
>> >>==========================
>> >>Eduardo Jedliczka
>> >>Gerasoft Informática
>> >>Apucarana - Pr
>> >>==========================
>> >>
>> >>----- Original Message -----
>> >>From: "Edson T. Marques" <marques em oriontec.com.br>
>> >>To: "FireBase" <lista em firebase.com.br>
>> >>Sent: Tuesday, May 03, 2005 4:16 PM
>> >>Subject: Re: [firebase-br] Identificador para tabelas
>> >>
>> >>
>> >>
>> >>>Ok!
>> >>>
>> >>>Sem querer ser chato... e já sendo, vamos a um exemplo prático.
>> >>>
>> >>>Meu banco de dados possui uma tabela de produtos com 70 campos. Essa
>> >>>tabela de produtos se relaciona com 10 outras tabelas:
>> >>>Grupos, SubGrupos, Classificações1, Classificações2, Classificações3,
>> >>>Classificações4, Fabricantes, Unidades, CategoriasDimensionais e
>> >>>ClassificaçãoFiscal.
>> >>>Em cada uma dessas tabelas existe uma chave primária que tem um
>> >>>relacionamento com a tabela de produtos e existe outro campo VARCHAR
> com
>> >>>a descrição.
>> >>>A tabela de produtos, portanto, possui um índice de fk para cada chave
>> >>>do relacionamento.
>> >>>
>> >>>Atualmente, então, minha tabela de produtos possui os 70 campos que
>> >>>falei mais 10 campos com as chaves das tabelas com que se relaciona.
>> >>>Alem disso mais 10 campos calculados com select (daquele jeito) para 
>> >>>me
>> >>>dar as descrições dos registros das tabelas com as quais a tabela de
>> >>>produto se relaciona.
>> >>>
>> >>>Assim:
>> >>>
>> >>>CREATE TABLE PRODUTO (
>> >>>   CHAVEPRO INTEGER NOT NULL,
>> >>>   CHAVEGRU CHAR(3),
>> >>>   CHAVESGR CHAR(3),
>> >>>   CHAVECL1 CHAR(3),
>> >>>   CHAVECL2 CHAR(3),
>> >>>   CHAVECL3 CHAR(3),
>> >>>   CHAVECL4 CHAR(3),
>> >>>   CHAVEFAB CHAR(3),
>> >>>   CHAVECDI NUMERIC(2,0) DEFAULT 0,
>> >>>   CHAVECLF VARCHAR(2),
>> >>>   UNIDADE VARCHAR(3) NOT NULL,
>> >>>   REFERENCIA VARCHAR(15),
>> >>>   NOME VARCHAR(50) NOT NULL COLLATE WIN_PTBR,
>> >>>   NOMEECF VARCHAR(30),
>> >>>   COMPLEMENTO VARCHAR(256),
>> >>>   COR VARCHAR(10),
>> >>>...
>> >>>
>> >>>  FABRICANTE COMPUTED BY ((select Nome from Fabricante F where
>> >>>F.ChaveFab = Produto.ChaveFab)),
>> >>>  GRUPO COMPUTED BY ((select Nome from Grupo G where G.ChaveGru =
>> >>>Produto.ChaveGru)),
>> >>>  SUBGRUPO COMPUTED BY ((select Nome from SubGrupo S where S.ChaveSGr 
>> >>> =
>> >>>Produto.ChaveSGr)),
>> >>>  CLASSIFIC1 COMPUTED BY ((select Nome from Classific1 C where
>> >>>C.ChaveCl1 = Produto.ChaveCl1)),
>> >>>  CLASSIFIC2 COMPUTED BY ((select Nome from Classific2 C where
>> >>>C.ChaveCl2 = Produto.ChaveCl2)),
>> >>>  CLASSIFIC3 COMPUTED BY ((select Nome from Classific3 C where
>> >>>C.ChaveCl3 = Produto.ChaveCl3)),
>> >>>  CLASSIFIC4 COMPUTED BY ((select Nome from Classific4 C where
>> >>>C.ChaveCl4 = Produto.ChaveCl4)),
>> >>>  DESCRCDIM COMPUTED BY ((select Descricao from CatDimens C where
>> >>>C.ChaveCDi = Produto.ChaveCDi)),
>> >>>  CLASSFISC COMPUTED BY ((select CODIGO from CLASSFISC C where
>> >>>C.ChaveClF = Produto.ChaveClF)),
>> >>>  ...
>> >>>);
>> >>>
>> >>>Então, na interface (cliente) eu só dou um select nessa tabela e tenho
>> >>>todos os campos que necessito.
>> >>>Aí beleza, É o que eu tenho atualmente.
>> >>>Neste caso você me orientaria a mudar essa estrutura, eliminar os
> campos
>> >>>calculados e fazer joins para obter o campos na interface. Dessa forma
>> >>>eu teria uma performance muito melhor?
>> >>>
>> >>>Seria isso?
>> >>>
>> >>>
>> >>>
>> >>>______________________________________________
>> >>>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
>> >>
>> >>>
>> >>
>> >>
>> >>______________________________________________
>> >>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=rebase
>> >>
>> >>
>> >>
>> >
>> >
>> > ______________________________________________
>> > 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
>> >
>>
>>
>>
>>
>>
>> ______________________________________________
>> 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
>
>
> ______________________________________________
> 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
>

Mais detalhes sobre a lista de discussão lista