----------------------------------------
> From: leandro.gfc.du...@gmail.com
> Date: Tue, 29 Dec 2009 17:24:55 -0200
> To: pgbr-geral@listas.postgresql.org.br
> Subject: Re: [pgbr-geral] Qual estrutura utilizar?
>
> 2009/12/29 Marcal Hokama :
>>
>> com o volume de dados envolvido, não há dúvidas de que vai ser necessário um
>> modelo diferenciado do modelo transacional
>
> Não necessariamente… não sabemos o suficiente sobre complexidade dos
> cálculos, como serão executados, como serão consultados os resultados…
> se esses volumes serão gerados ou apenas usados… se o gargalo é
> processamento ou E/S (geralmente é E/S)…
>
Concordo, mas pelo que foi informado: "A Classificação que mencionei, são
cálculos de vendas nos últimos 3 meses (aproximadamente 4.500.000 registros),
30 dias (aproximadamente1.500.000 registros), 13800 produtos, das 55 filiais
(solicitação deamigos consultores..rssss)."
Já pode se perceber que relatórios tipo vendas x produto, vendas x filial,
vendas x produto x filial, com as quantidades envolvidas, haverá uma demanda de
processamento (envolvendo CPU, memória e E/S), até por outra informação dada: "
porém quando inicia a execução das classificações o desempenho do servidor cai
drasticamente."
> Outra coisa, muito que geralmente se considera como ‘modelo
> diferenciado do transacional’ pode ser implantado com extensões deste
> último, como visões materializadas, gatilhos &c.
Uma solução pode ser a armazenagem dos dados consolidados para tornar mais
rápida a emissão de relatórios. Pode ser tanto tabelas ou views materializadas
modeladas de acordo com a necessidade e do relatório a ser emitido. Para a
alimentação destas estruturas podem ser utilizadas rotinas em lote ou triggers.
São detalhes de implementação, mas o importante é que é bem provável que o
modelo atual (transacional) nao atenderá a essa necessidade de emissão de
relatórios em tempo real, sendo necessária a criação de novas estruturas para
atender a essa finalidade. Mas a sua implementação vai depender, basicamente,
da periodicidade em que as rotinas de consolidação serão executadas.
> Datamart e modelo dimensional (como, aliás, prefixos de nomes de
> objetos, chaves artificiais, desnormalização &c) amiúde são as
> respostas certas para as questões erradas — ou respostas em buscas de
> questões.
>
>
Tudo depende do contexto em que vai ser aplicado. Existem soluções que não são
adequadas para determinados casos e para outros são.
> --
> skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org
> +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
> Sent from Sao Paulo, SP, Brazil
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Marçal de Lima Hokama
---------------------
_________________________________________________________________
Fique protegido de ameças utilizando o Novo Internet Explorer 8. Baixe já, é
grátis!
http://brasil.microsoft.com.br/IE8/mergulhe/?utm_source=MSN%3BHotmail&utm_medium=Tagline&utm_content=Tag1&utm_campaign=IE8
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
