topic Re: ASSOCIACAO X JOIN in Brasil https://community.qlik.com/t5/Brasil/ASSOCIACAO-X-JOIN/m-p/1428329#M52217 <HTML><HEAD></HEAD><BODY><P>Paulo, tudo depende.</P><P></P><P>Um modelo Star, Snow Flake ou Big Facto somente terá performance melhor ou pior entre eles dependendo da quantidade de registros entre as tabelas.</P><P></P><P><IMG alt="2017-09-17 15_08_51-Apresentacao Completo.pptx - PowerPoint.png" class="jive-image image-1" src="/legacyfs/online/176853_2017-09-17 15_08_51-Apresentacao Completo.pptx - PowerPoint.png" style="height: 268px; width: 620px;" /></P><P><IMG alt="2017-09-17 15_09_15-Apresentacao Completo.pptx - PowerPoint.png" class="jive-image image-2" src="/legacyfs/online/176854_2017-09-17 15_09_15-Apresentacao Completo.pptx - PowerPoint.png" style="height: 192px; width: 620px;" /></P><P></P><P>Então, se tiver um modelo SnowFlake com poucos registros nas pontas (4 hops no exemplo acima com poucos registros nas pontas) a performance não vai ser diferente do bigfacto, conforme <A href="https://community.qlik.com/qlik-blogpost/4039">A Myth about the Number of Hops</A></P><P></P><P>Se tiver grandes quantidades nas pontas, então melhor juntar. </P><P></P><P>Agora, tem questões a serem consideradas, por exemplo se tiver calculo de campos entre as tabelas.</P><P></P><P>Se na expressão tiver campos de tabelas diferentes – exemplo&nbsp;&nbsp;&nbsp; sum(Pedido_Qtde * TabelaPreco_ValorUnitario) “poderá” criar piora na performance (terá que criar o lookup das tabelas..(join)&nbsp; em tempo de calculo). Neste caso seria melhor ter (se possível) os dados já na mesma "linha" ou mesmo já calculado.</P><P></P><P>A performance não esta somente na modelagem.&nbsp; Está em como o campo é lido e gravado ( <A href="https://community.qlik.com/qlik-blogpost/2848">Symbol Tables and Bit-Stuffed Pointers</A> ) , se tenho expressões com if (poderia usar set analisys ) , uso aggr ( que cria uma tabela virtual para calcular. E aqui também não estou dizendo que não pode usar, mas cuidar......), condicoes de calculo ajudam na performance tambem, pois evita o calculo desnecessario quando o usuario limpa todas as selecoes por exemplo.</P><P></P><P>enfim, bastante coisa....como salvar com compressão ou não (se a carga é feita em tempos curtos....), variáveis ( certo <A href="https://community.qlik.com/qlik-users/28979">nicolett.yuri</A>&nbsp; <IMG src="https://community.qlik.com/legacyfs/online/emoticons/happy.png" /> ) etc....</P></BODY></HTML> Sun, 17 Sep 2017 18:26:04 GMT afurtado 2017-09-17T18:26:04Z ASSOCIACAO X JOIN https://community.qlik.com/t5/Brasil/ASSOCIACAO-X-JOIN/m-p/1428328#M52216 <HTML><HEAD></HEAD><BODY><P>Senhores bom dia, gostaria de um auxilio, na verdade é mais uma duvida, como melhor pratica em se tratando de performance da aplicacao, qual a melhor forma de trabalhar com tabelas , é realizando uma associacao entre tabelas ou realizando um join? Obrigado a todos.</P></BODY></HTML> Sun, 17 Sep 2017 13:49:10 GMT https://community.qlik.com/t5/Brasil/ASSOCIACAO-X-JOIN/m-p/1428328#M52216 paulomulato 2017-09-17T13:49:10Z Re: ASSOCIACAO X JOIN https://community.qlik.com/t5/Brasil/ASSOCIACAO-X-JOIN/m-p/1428329#M52217 <HTML><HEAD></HEAD><BODY><P>Paulo, tudo depende.</P><P></P><P>Um modelo Star, Snow Flake ou Big Facto somente terá performance melhor ou pior entre eles dependendo da quantidade de registros entre as tabelas.</P><P></P><P><IMG alt="2017-09-17 15_08_51-Apresentacao Completo.pptx - PowerPoint.png" class="jive-image image-1" src="/legacyfs/online/176853_2017-09-17 15_08_51-Apresentacao Completo.pptx - PowerPoint.png" style="height: 268px; width: 620px;" /></P><P><IMG alt="2017-09-17 15_09_15-Apresentacao Completo.pptx - PowerPoint.png" class="jive-image image-2" src="/legacyfs/online/176854_2017-09-17 15_09_15-Apresentacao Completo.pptx - PowerPoint.png" style="height: 192px; width: 620px;" /></P><P></P><P>Então, se tiver um modelo SnowFlake com poucos registros nas pontas (4 hops no exemplo acima com poucos registros nas pontas) a performance não vai ser diferente do bigfacto, conforme <A href="https://community.qlik.com/qlik-blogpost/4039">A Myth about the Number of Hops</A></P><P></P><P>Se tiver grandes quantidades nas pontas, então melhor juntar. </P><P></P><P>Agora, tem questões a serem consideradas, por exemplo se tiver calculo de campos entre as tabelas.</P><P></P><P>Se na expressão tiver campos de tabelas diferentes – exemplo&nbsp;&nbsp;&nbsp; sum(Pedido_Qtde * TabelaPreco_ValorUnitario) “poderá” criar piora na performance (terá que criar o lookup das tabelas..(join)&nbsp; em tempo de calculo). Neste caso seria melhor ter (se possível) os dados já na mesma "linha" ou mesmo já calculado.</P><P></P><P>A performance não esta somente na modelagem.&nbsp; Está em como o campo é lido e gravado ( <A href="https://community.qlik.com/qlik-blogpost/2848">Symbol Tables and Bit-Stuffed Pointers</A> ) , se tenho expressões com if (poderia usar set analisys ) , uso aggr ( que cria uma tabela virtual para calcular. E aqui também não estou dizendo que não pode usar, mas cuidar......), condicoes de calculo ajudam na performance tambem, pois evita o calculo desnecessario quando o usuario limpa todas as selecoes por exemplo.</P><P></P><P>enfim, bastante coisa....como salvar com compressão ou não (se a carga é feita em tempos curtos....), variáveis ( certo <A href="https://community.qlik.com/qlik-users/28979">nicolett.yuri</A>&nbsp; <IMG src="https://community.qlik.com/legacyfs/online/emoticons/happy.png" /> ) etc....</P></BODY></HTML> Sun, 17 Sep 2017 18:26:04 GMT https://community.qlik.com/t5/Brasil/ASSOCIACAO-X-JOIN/m-p/1428329#M52217 afurtado 2017-09-17T18:26:04Z Re: ASSOCIACAO X JOIN https://community.qlik.com/t5/Brasil/ASSOCIACAO-X-JOIN/m-p/1428330#M52218 <HTML><HEAD></HEAD><BODY><P>Obrigado pelo retorno Alessandro, alucidou muita coisa que estava tentando desvendar</P></BODY></HTML> Mon, 18 Sep 2017 00:37:10 GMT https://community.qlik.com/t5/Brasil/ASSOCIACAO-X-JOIN/m-p/1428330#M52218 paulomulato 2017-09-18T00:37:10Z