Problema com muitas inserções

[Wagner Bonfiglio]

Olá a todos...

Atualmente estou com um problema em meu site devido a muitas inserções
no banco de dados na hora que um usuário se cadastro.
Vou tentar explicar um pouco meu caso..

Eu tenho um site sobre filmes, que também é uma reede social. Temos
atualmente cerca de 1000 usuários e 11000 filmes.

A modelagem, devido a alguns cálculos que são feitos, acabou definindo
que cada usuário tenha uma entrada em uma tabela relacionando cada um
dos outros usuários, além de uma entrada em outra tabela que relaciona
cada usuário com cada filme.

Ou seja, quando um usuário é criado, eu tenho que inserir 1000
entradas na tabela q liga usuarios com usuarios, e 11000 entradas na
tabela que relaciona filmes com usuarios.
Isso é feito através de uma função em plpgsql disparada por uma
trigger no insert da tabela de usuarios.
O problema pro usuário é ter que esperar esses 12000 inserts
acontecerem (atualmante esta demorando 2min, mas a tendencia é
continuar crescendo tanto em usuarios como em filmes) durante o
cadastro.

Já não sei mais o que fazer para melhorar isso, pois tem muitos
usuários que não esperam os inserts e fecham a página no meio,
causando diversos erros na hora de tentar logar no site...


Minhas dúvidas são:
 - essa prática de inserir todas essas entradas na hora do cadastro é
errado ou não tem problema?
 - a demora é porque o servidor está muito lento (ou seja, esses 12000
inserts deveriam ser mais rapidos)??
 - você chegou aqui entendendo o que eu quis dizer? hahaha não sei se
fui muito claro no problema, mas uma coisa interessante de citar é que
essas entradas entre todos os clientes e entre os clientes e todos os
filmes é importante pois o site calcula notas sugeridas para cada
usuário, dependendo dos votos deles e da semelhança dos votos com
outros usuários.


Bom, se precisarem de mais detalhes sobre o caso eu posso comentar
mais aqui (não sei se tem problema em passar o site, então achei
melhor nem colocar o link). Mas espero que possam me ajudar de
qualquer forma, qualquer toque será bem vindo!

Valeu,
    Wagner Mariotto Bonfiglio
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Leandro DUTRA]

2008/7/7 Wagner Bonfiglio <wmbonfiglio@...>:
>  - essa prática de inserir todas essas entradas na hora do cadastro é
> errado ou não tem problema?

Erradíssimo.


>  - você chegou aqui entendendo o que eu quis dizer? hahaha não sei se
> fui muito claro no problema, mas uma coisa interessante de citar é que
> essas entradas entre todos os clientes e entre os clientes e todos os
> filmes é importante pois o site calcula notas sugeridas para cada
> usuário, dependendo dos votos deles e da semelhança dos votos com
> outros usuários.

Isso é absurdo, imagina esse sistema se popularizando!

Teria de repensar todo o modelo de dados, não sei se a lista é
adequada para esse tipo de discussão.  Eu, particularmente,
recomendaria a consultoria de um administrador de dados experiente.
Muitos DBAs também poderiam ajudar.

--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
[phone] r155 gTalk: xmpp:leandrod@...
[phone] ICQ/AIM: aim:GoIM?screenname=61287803
[phone] MSN: msnim:chat?contact=leandro@...
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Mozart Hasse]

Wagner,

> Minhas dúvidas são:
> - essa prática de inserir todas essas entradas na hora do cadastro é
> errado ou não tem problema?

Provavelmente há maneiras melhores.
É, no mínimo, uma alternativa não recomendada e só justificável em
raríssimos casos.

> - a demora é porque o servidor está muito lento (ou seja, esses 12000
> inserts deveriam ser mais rapidos)??

12000 registros em *dois* intermináveis minutos?! Eu acho que está
horrivelmente
lento até para uma estaçãozinha Windows com 512K de RAM e um mísero disco
IDE,
transformada em servidor de e-mail e Postgres. Tua tabela está entupida de
índices e
chaves estrangeiras (mais de 10?) ?! Mesmo que esteja, tenho lá minhas
dúvidas que
leve isso tudo. Veja se consegue fazer os 12000 inserts num comando só
(INSERT INTO SELECT), caso não esteja fazendo isso. Você pode também tentar
dividir essa tabela em outras menores (com menos campos),
para que o insert seja sobre uma tabela com registros e índices menores.

>  - você chegou aqui entendendo o que eu quis dizer? hahaha não sei se
> fui muito claro no problema, mas uma coisa interessante de citar é que
> essas entradas entre todos os clientes e entre os clientes e todos os
> filmes é importante pois o site calcula notas sugeridas para cada
> usuário, dependendo dos votos deles e da semelhança dos votos com
> outros usuários.

Não sei se isso justifica inserir 12000 registros, mas enquanto não tiver
oção melhor...
Outra coisa que sempre dá para fazer é deixar essa inserção como um processo
em
segundo plano, em outra transação independente. Você cadastra o cara numa
transação
minúscula (INSERT na tabela de usuários e era isso) e deixa o registro dele
*marcado* como
*pendente* (sim, isso pode dar trabalho para tratar nas outras telas do
sistema, mas você
quer uma alternativa com desempenho *viável*, não quer?!). Um outro processo
(que você vai precisar implementar) roda de tempos em tempos vendo quem está
pendente e lasca o INSERT nos registros que encontrar, alterando a situação
quando for bem sucedido.
Enquanto este segundo passo não for feito, o cara fica cadastrado, mas ainda
não acessa
toda a funcionalidade do site (porém já tem login e senha garantidos) nem
entra na conta
dessa tabela de 12000 registros por cabeça, mantendo sua transação de
cadastro bem
leve.
Bom, vai um bom aviso: apelar para processos em segundo plano é um caso
*_*_e_x_t_r_e_m_o_*_* (leia-se esta palavra com fonte grande, negrito,
itálico e sublinhado)
que só deveria ser aplicado se não houver outra maneira de guardar os dados
que você precisa
nessa tabela todos-com-todos. Acho muito provável que você possa transformar
essa tabela em
duas ou três tabelas menores com uma aparente redundância e índices bem
escolhidos, e que
essas tabelas possam te dar o desempenho necessário  ou mesmo superior com
uma fração
do número de registros que você tem hoje.

Atenciosamente,

Mozart Hasse


_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Alexsandro Haag]

Possivelmente não foi previsto este crescimento da base no início do projeto.
Na época não estava impactando, agora que está talvez seja o caso de avaliar outra alternativa.

Talvez deixar este processo para rodar através de uma rotina em determinados momentos, não no momento do cadastro.

Mas seria necessário conhecer o projeto melhor para sugerir alternativas, pois esta acima pode não ser possível devido a algum outra regra de negócio do sistema.

Como o Leandro comentou, o ideal seria envolver uma consultoria para resolver esta questão da melhor forma.

Att.
Alex

Leandro DUTRA escreveu:

2008/7/7 Wagner Bonfiglio wmbonfiglio@...:
  

 - essa prática de inserir todas essas entradas na hora do cadastro é
errado ou não tem problema?
    

Erradíssimo.


  

 - você chegou aqui entendendo o que eu quis dizer? hahaha não sei se
fui muito claro no problema, mas uma coisa interessante de citar é que
essas entradas entre todos os clientes e entre os clientes e todos os
filmes é importante pois o site calcula notas sugeridas para cada
usuário, dependendo dos votos deles e da semelhança dos votos com
outros usuários.
    

Isso é absurdo, imagina esse sistema se popularizando!

Teria de repensar todo o modelo de dados, não sei se a lista é
adequada para esse tipo de discussão.  Eu, particularmente,
recomendaria a consultoria de um administrador de dados experiente.
Muitos DBAs também poderiam ajudar.

  

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Shander Lyrio]

Wagner Bonfiglio escreveu:

> Eu tenho um site sobre filmes, que também é uma reede social. Temos
> atualmente cerca de 1000 usuários e 11000 filmes.
 >
> A modelagem, devido a alguns cálculos que são feitos, acabou definindo
> que cada usuário tenha uma entrada em uma tabela relacionando cada um
> dos outros usuários, além de uma entrada em outra tabela que relaciona
> cada usuário com cada filme.
>
> Ou seja, quando um usuário é criado, eu tenho que inserir 1000
> entradas na tabela q liga usuarios com usuarios, e 11000 entradas na
> tabela que relaciona filmes com usuarios.

        Afe Deus, quais cálculos levaram vocês a uma modelagem destas??

> Isso é feito através de uma função em plpgsql disparada por uma
> trigger no insert da tabela de usuarios.

        Nuss.

> O problema pro usuário é ter que esperar esses 12000 inserts
> acontecerem (atualmante esta demorando 2min, mas a tendencia é
> continuar crescendo tanto em usuarios como em filmes) durante o
> cadastro.
>
> Já não sei mais o que fazer para melhorar isso, pois tem muitos
> usuários que não esperam os inserts e fecham a página no meio,
> causando diversos erros na hora de tentar logar no site...

        Que tal refazer a modelagem. Esta forma de fazer está claramente
equivocada.

> Minhas dúvidas são:
>  - essa prática de inserir todas essas entradas na hora do cadastro é
> errado ou não tem problema?

        É errado, melhor dizendo, não recompendávelem  pelo menos 99,99999% dos
casos.

>  - a demora é porque o servidor está muito lento (ou seja, esses 12000
> inserts deveriam ser mais rapidos)??

        A demora é porque a forma de fazer está equivocada. Para que ou porque
isso tudo?? Poderia explicar melhor para tentarmos ajudar mais
efetivamente??

>  - você chegou aqui entendendo o que eu quis dizer? hahaha não sei se
> fui muito claro no problema, mas uma coisa interessante de citar é que
> essas entradas entre todos os clientes e entre os clientes e todos os
> filmes é importante pois o site calcula notas sugeridas para cada
> usuário, dependendo dos votos deles e da semelhança dos votos com
> outros usuários.

        Existem formas muito mais simples de se fazer estes cálculos, caso
contrário o orkut teria um lag de horas ao se cadastrar um novo usuário.
Vocês precisam repensar esta forma, ou contratar uma consultoria para
fazê-lo. Mas nada poderá ser feito se vocês não tiverem a clara idéia de
que isto precisa ser mudado.

> Bom, se precisarem de mais detalhes sobre o caso eu posso comentar
> mais aqui (não sei se tem problema em passar o site, então achei
> melhor nem colocar o link). Mas espero que possam me ajudar de
> qualquer forma, qualquer toque será bem vindo!

        Veja, seu problema não é o PostGreSql, é modelagem. A forma de fazer
não está legal e precisa ser repensada. Acredito que um DBA na equipe
pudesse auxiliar mais efetivamente.

--
Shander Lyrio
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Shander Lyrio]

Wagner Bonfiglio escreveu:
>
> Mas enfim, estamos trabalhando em mudar isso já, mas faltam algumas
> idéias de quais as melhores opções e quais idéias só vão resolver
> momentaneamente e teremos mais prolemas no futuro.
>
> Agradeço as respostas até agora e qualquer outra sugestão/crítica/etc
> será muito bem-vinda!

        A comunidade sempre vai estar aqui para ajudar no que for preciso, mas
para isto precisamos de mais informações sobre como são realizados estes
cálculos. De qualquer forma, um DBA seria muito mais efetivo e rápido no
seu projeto.

        Pelo histórico que conheço da lista, modelagem gera muitas discussões e
opiniões que simplesmente podem distorcer de sua realidade - normal de
quem não conhece a fundo suas necessidades. Portanto existe um risco de
você ler coisas que não gostaria muito caso resolva discutir este
assunto aqui. Temos nesta lista profissionais extremamente gabaritados e
de alto conteúdo assim como temos também colegas que estão iniciando na
área. Se você quiser arriscar?!?! Estamos por aqui!

        Abraço,


--
Shander Lyrio
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Wagner Bonfiglio]

Bom, tentando explicar um pouco o motivo de tanta inserção:

como o Alexandre falou, sobre a previsão de crescimento.. A idéia
desde o começo foi crescer muito mais que estamos atualmente, mas não
foi pensado na consequencia que teriamos nesse banco de dados.

Na verdade não fui eu que modelei, mas já passamos por alguns
problemas e algumas coisas já foram melhoradas porque começou a dar
problema em certo ponto.
Atualmente o problema que surgiu agora, com mais de 1000 usuarios e
11000 filmes é essa inserção na hora do cadastro.

Quanto a esta inserção, que eu concordo que está errada pois quanto
mais cresce o número de filmes e/ou usuários esse problema vai
aumentar ainda mais, era algo necessário na idéia inicial devido a um
cálculo, como eu falei. O que acontece? Cada usuário tem um certo
nível de similariedade com cada outro usuário. Isso é calculado a cada
nota que um usuário dá. Além disso, a cada X notas, as notas sugeridas
pra os filmes que você não assistiu também é calculada.
Para evitar que esses INSERTS sejam feitos na hora do cálculo, fazemos
tudo na hora do cadastro. Há algum tempo isso não era problema,
demorava menos de 1 minuto, mas agora está começando a virar
problema...

Bom, agora acho que dá pra entender melhor o caso e porque da opção dos
INSERTS na hora do cadastro. Faltou uma visão de problemas que isto
ocasionariam no futuro.

Mas enfim, estamos trabalhando em mudar isso já, mas faltam algumas
idéias de quais as melhores opções e quais idéias só vão resolver
momentaneamente e teremos mais prolemas no futuro.

Agradeço as respostas até agora e qualquer outra sugestão/crítica/etc
será muito bem-vinda!

Grato,
    Wagner Bonfiglio

2008/7/8 Shander Lyrio <shanderlyrio@...>:

>
>
> Wagner Bonfiglio escreveu:
>
>> Eu tenho um site sobre filmes, que também é uma reede social. Temos
>> atualmente cerca de 1000 usuários e 11000 filmes.
>  >
>> A modelagem, devido a alguns cálculos que são feitos, acabou definindo
>> que cada usuário tenha uma entrada em uma tabela relacionando cada um
>> dos outros usuários, além de uma entrada em outra tabela que relaciona
>> cada usuário com cada filme.
>>
>> Ou seja, quando um usuário é criado, eu tenho que inserir 1000
>> entradas na tabela q liga usuarios com usuarios, e 11000 entradas na
>> tabela que relaciona filmes com usuarios.
>
>        Afe Deus, quais cálculos levaram vocês a uma modelagem destas??
>
>> Isso é feito através de uma função em plpgsql disparada por uma
>> trigger no insert da tabela de usuarios.
>
>        Nuss.
>
>> O problema pro usuário é ter que esperar esses 12000 inserts
>> acontecerem (atualmante esta demorando 2min, mas a tendencia é
>> continuar crescendo tanto em usuarios como em filmes) durante o
>> cadastro.
>>
>> Já não sei mais o que fazer para melhorar isso, pois tem muitos
>> usuários que não esperam os inserts e fecham a página no meio,
>> causando diversos erros na hora de tentar logar no site...
>
>        Que tal refazer a modelagem. Esta forma de fazer está claramente
> equivocada.
>
>> Minhas dúvidas são:
>>  - essa prática de inserir todas essas entradas na hora do cadastro é
>> errado ou não tem problema?
>
>        É errado, melhor dizendo, não recompendávelem  pelo menos 99,99999% dos
> casos.
>
>>  - a demora é porque o servidor está muito lento (ou seja, esses 12000
>> inserts deveriam ser mais rapidos)??
>
>        A demora é porque a forma de fazer está equivocada. Para que ou porque
> isso tudo?? Poderia explicar melhor para tentarmos ajudar mais
> efetivamente??
>
>>  - você chegou aqui entendendo o que eu quis dizer? hahaha não sei se
>> fui muito claro no problema, mas uma coisa interessante de citar é que
>> essas entradas entre todos os clientes e entre os clientes e todos os
>> filmes é importante pois o site calcula notas sugeridas para cada
>> usuário, dependendo dos votos deles e da semelhança dos votos com
>> outros usuários.
>
>        Existem formas muito mais simples de se fazer estes cálculos, caso
> contrário o orkut teria um lag de horas ao se cadastrar um novo usuário.
> Vocês precisam repensar esta forma, ou contratar uma consultoria para
> fazê-lo. Mas nada poderá ser feito se vocês não tiverem a clara idéia de
> que isto precisa ser mudado.
>
>> Bom, se precisarem de mais detalhes sobre o caso eu posso comentar
>> mais aqui (não sei se tem problema em passar o site, então achei
>> melhor nem colocar o link). Mas espero que possam me ajudar de
>> qualquer forma, qualquer toque será bem vindo!
>
>        Veja, seu problema não é o PostGreSql, é modelagem. A forma de fazer
> não está legal e precisa ser repensada. Acredito que um DBA na equipe
> pudesse auxiliar mais efetivamente.
>
> --
> Shander Lyrio
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@...
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Alexsandro Haag]

Poderia talvez gerar um registro de pendência para este procedimento. Ao invés de gerar vários inserts geraria apenas um.
Depois algum job do cron poderia varrer esta tabela de pendências e gerar os registros no intervalo de tempo aceitável.

Att.
Alex


Wagner Bonfiglio escreveu:

Bom, tentando explicar um pouco o motivo de tanta inserção:

como o Alexandre falou, sobre a previsão de crescimento.. A idéia
desde o começo foi crescer muito mais que estamos atualmente, mas não
foi pensado na consequencia que teriamos nesse banco de dados.

Na verdade não fui eu que modelei, mas já passamos por alguns
problemas e algumas coisas já foram melhoradas porque começou a dar
problema em certo ponto.
Atualmente o problema que surgiu agora, com mais de 1000 usuarios e
11000 filmes é essa inserção na hora do cadastro.

Quanto a esta inserção, que eu concordo que está errada pois quanto
mais cresce o número de filmes e/ou usuários esse problema vai
aumentar ainda mais, era algo necessário na idéia inicial devido a um
cálculo, como eu falei. O que acontece? Cada usuário tem um certo
nível de similariedade com cada outro usuário. Isso é calculado a cada
nota que um usuário dá. Além disso, a cada X notas, as notas sugeridas
pra os filmes que você não assistiu também é calculada.
Para evitar que esses INSERTS sejam feitos na hora do cálculo, fazemos
tudo na hora do cadastro. Há algum tempo isso não era problema,
demorava menos de 1 minuto, mas agora está começando a virar
problema...

Bom, agora acho que dá pra entender melhor o caso e porque da opção dos
INSERTS na hora do cadastro. Faltou uma visão de problemas que isto
ocasionariam no futuro.

Mas enfim, estamos trabalhando em mudar isso já, mas faltam algumas
idéias de quais as melhores opções e quais idéias só vão resolver
momentaneamente e teremos mais prolemas no futuro.

Agradeço as respostas até agora e qualquer outra sugestão/crítica/etc
será muito bem-vinda!

Grato,
    Wagner Bonfiglio

2008/7/8 Shander Lyrio shanderlyrio@...:
  

Wagner Bonfiglio escreveu:

    

Eu tenho um site sobre filmes, que também é uma reede social. Temos
atualmente cerca de 1000 usuários e 11000 filmes.
      

 >
    

A modelagem, devido a alguns cálculos que são feitos, acabou definindo
que cada usuário tenha uma entrada em uma tabela relacionando cada um
dos outros usuários, além de uma entrada em outra tabela que relaciona
cada usuário com cada filme.

Ou seja, quando um usuário é criado, eu tenho que inserir 1000
entradas na tabela q liga usuarios com usuarios, e 11000 entradas na
tabela que relaciona filmes com usuarios.
      

       Afe Deus, quais cálculos levaram vocês a uma modelagem destas??

    

Isso é feito através de uma função em plpgsql disparada por uma
trigger no insert da tabela de usuarios.
      

       Nuss.

    

O problema pro usuário é ter que esperar esses 12000 inserts
acontecerem (atualmante esta demorando 2min, mas a tendencia é
continuar crescendo tanto em usuarios como em filmes) durante o
cadastro.

Já não sei mais o que fazer para melhorar isso, pois tem muitos
usuários que não esperam os inserts e fecham a página no meio,
causando diversos erros na hora de tentar logar no site...
      

       Que tal refazer a modelagem. Esta forma de fazer está claramente
equivocada.

    

Minhas dúvidas são:
 - essa prática de inserir todas essas entradas na hora do cadastro é
errado ou não tem problema?
      

       É errado, melhor dizendo, não recompendávelem  pelo menos 99,99999% dos
casos.

    

 - a demora é porque o servidor está muito lento (ou seja, esses 12000
inserts deveriam ser mais rapidos)??
      

       A demora é porque a forma de fazer está equivocada. Para que ou porque
isso tudo?? Poderia explicar melhor para tentarmos ajudar mais
efetivamente??

    

 - você chegou aqui entendendo o que eu quis dizer? hahaha não sei se
fui muito claro no problema, mas uma coisa interessante de citar é que
essas entradas entre todos os clientes e entre os clientes e todos os
filmes é importante pois o site calcula notas sugeridas para cada
usuário, dependendo dos votos deles e da semelhança dos votos com
outros usuários.
      

       Existem formas muito mais simples de se fazer estes cálculos, caso
contrário o orkut teria um lag de horas ao se cadastrar um novo usuário.
Vocês precisam repensar esta forma, ou contratar uma consultoria para
fazê-lo. Mas nada poderá ser feito se vocês não tiverem a clara idéia de
que isto precisa ser mudado.

    

Bom, se precisarem de mais detalhes sobre o caso eu posso comentar
mais aqui (não sei se tem problema em passar o site, então achei
melhor nem colocar o link). Mas espero que possam me ajudar de
qualquer forma, qualquer toque será bem vindo!
      

       Veja, seu problema não é o PostGreSql, é modelagem. A forma de fazer
não está legal e precisa ser repensada. Acredito que um DBA na equipe
pudesse auxiliar mais efetivamente.

--
Shander Lyrio
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

    

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

  

_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Leandro DUTRA]

2008/7/8 Wagner Bonfiglio <wmbonfiglio@...>:
> como o Alexandre falou, sobre a previsão de crescimento.. A idéia
> desde o começo foi crescer muito mais que estamos atualmente, mas não
> foi pensado na consequencia que teriamos nesse banco de dados.

Wagner, baseado em alguns anos de experiência, creio que vocês terão
muitos outros problemas.  O ideal realmente seria incorporar ao
projeto, nem que seja como consultor externo esporádico, alguém com
mais visão de dados, para entender toda a base e preparar para o
futuro, sem incorrer em otimizações precoces.

Essa opção de similaridade com cada usuário parece, a princípio,
totalmente inviável, a menos que você tenha uma infra do tipo Google,
Yahoo!, MS ou Amazon.  Teria de repensar isso do zero, creio.  Talvez
algo como manter um perfil do usuário que seja facilmente comparável
ad hoc, em vez de calculado a cada transação.

Mas é impossível dar sugestões decentes sem estar dentro do projeto.

--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
[phone] r155 gTalk: xmpp:leandrod@...
[phone] ICQ/AIM: aim:GoIM?screenname=61287803
[phone] MSN: msnim:chat?contact=leandro@...
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[José Mello Júnior]

Quando o usuário for dar a sua nota para determinado filme, crie o registro, assim se não houver registro, considere simplesmente que o usuário não deu nota, esta atitude diminuirá substancialemente a quantidade de registros na tabela e trará a necessidade de insert para zero no momento de cadastro do usuário.

 

[]´s

2008/7/8 Shander Lyrio <shanderlyrio@...>:

Wagner Bonfiglio escreveu:

>
> Mas enfim, estamos trabalhando em mudar isso já, mas faltam algumas
> idéias de quais as melhores opções e quais idéias só vão resolver
> momentaneamente e teremos mais prolemas no futuro.
>
> Agradeço as respostas até agora e qualquer outra sugestão/crítica/etc
> será muito bem-vinda!

       A comunidade sempre vai estar aqui para ajudar no que for preciso, mas
para isto precisamos de mais informações sobre como são realizados estes
cálculos. De qualquer forma, um DBA seria muito mais efetivo e rápido no
seu projeto.

       Pelo histórico que conheço da lista, modelagem gera muitas discussões e
opiniões que simplesmente podem distorcer de sua realidade - normal de
quem não conhece a fundo suas necessidades. Portanto existe um risco de
você ler coisas que não gostaria muito caso resolva discutir este
assunto aqui. Temos nesta lista profissionais extremamente gabaritados e
de alto conteúdo assim como temos também colegas que estão iniciando na
área. Se você quiser arriscar?!?! Estamos por aqui!

       Abraço,

--
Shander Lyrio
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

--
José de Mello Júnior
41.9957-2007
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Wagner Bonfiglio]

2008/7/8 Leandro DUTRA <leandro.gfc.dutra@...>:
> Essa opção de similaridade com cada usuário parece, a princípio,
> totalmente inviável, a menos que você tenha uma infra do tipo Google,
> Yahoo!, MS ou Amazon.  Teria de repensar isso do zero, creio.  Talvez
> algo como manter um perfil do usuário que seja facilmente comparável
> ad hoc, em vez de calculado a cada transação.
>
> Mas é impossível dar sugestões decentes sem estar dentro do projeto.

Pois é Leandro... As tuas sugestões já estão sendo úteis sim. Essa
parte de similariedade entre cada usuário agente já ta pra muda mesmo,
mas o problema é que a princípio não parecia algo tão absurdo...
Agora, com 1000 usuário, estamos começando a ter um problema
"pequeno", mas já vimos que será algo totalmente inviável mesmo. Valeu
pelas dicas e desculpa não dar detalhes maiores do projeto, mas
simplesmente não tenho essa autoriedade né... Você deve me entender
também.


2008/7/8 Shander Lyrio <shanderlyrio@...>:

>        A comunidade sempre vai estar aqui para ajudar no que for preciso, mas
> para isto precisamos de mais informações sobre como são realizados estes
> cálculos. De qualquer forma, um DBA seria muito mais efetivo e rápido no
> seu projeto.
>
>        Pelo histórico que conheço da lista, modelagem gera muitas discussões e
> opiniões que simplesmente podem distorcer de sua realidade - normal de
> quem não conhece a fundo suas necessidades. Portanto existe um risco de
> você ler coisas que não gostaria muito caso resolva discutir este
> assunto aqui. Temos nesta lista profissionais extremamente gabaritados e
> de alto conteúdo assim como temos também colegas que estão iniciando na
> área. Se você quiser arriscar?!?! Estamos por aqui!
>
>        Abraço,

Shander, eu faço parte do segundo grupo, daqueles que estão iniciando,
então a cada coisa que vocês mais experientes falam e distorcem minha
realidade eu fico grato, pois estou envolvido em meu primeiro grande
projeto profissional e estou tendo dificuldades imensas por conta da
inexperiência.
Como falei anteriormente eu não tenho autoridade para falar mais
detalhadamente sobre como o cálculo é feito né, até porque este é o
diferencial do site, mas a minha idéia é tentar passar o máximo que eu
puder e receber toda a ajuda que eu puder. Até me surpreendi, tive
boas respostas aqui passando não muitas informações né...
Mas então podem criticar a vontade pois é isso que eu quero mesmo, não
quero apenas uma solução pro meu negócio funcionar, mas também estou
tentando adquirir uma boa experiencia dos erros deste projeto (mas
claro, a prioridade é botar ele nos eixos novamente hehehe)


2008/7/8 José Mello Júnior <jose.mello.junior@...>:
> Quando o usuário for dar a sua nota para determinado filme, crie o registro,
> assim se não houver registro, considere simplesmente que o usuário não deu
> nota, esta atitude diminuirá substancialemente a quantidade de registros na
> tabela e trará a necessidade de insert para zero no momento de cadastro do
> usuário.
>
> []´s
>

José, o problema são os cálculos. A intenção era ter todas as
entradas, para na hora do cálculo, simplesmente mudar a nota que tinha
antigamente para a nova nota calculada, e não somar o trabalho de
calcular notas para diversos filmes e ainda fazer inserções no banco.
Porém, visto que a inclusão no registro não está dando certo, o jeito
vai ser repensar isso...



Mais uma vez agradeço a atenção de todos.
Att,
   Wagner Bonfiglio
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Leandro DUTRA]

2008/7/8 Wagner Bonfiglio <wmbonfiglio@...>:
> Valeu
> pelas dicas e desculpa não dar detalhes maiores do projeto

Não tem problema — você não tem obrigação.

E além de não ter obrigação, é aquilo que eu penso e já disse:
modelagem por correio eletrônico é muito, muito complicado, porque
depende de entender exatamente e em detalhes os requerimentos, a
arquitetura &c.


--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
[phone] r155 gTalk: xmpp:leandrod@...
[phone] ICQ/AIM: aim:GoIM?screenname=61287803
[phone] MSN: msnim:chat?contact=leandro@...
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Osvaldo Kussama]

Wagner Bonfiglio escreveu:
>>
>> Mas é impossível dar sugestões decentes sem estar dentro do projeto.
>

Leve em conta isto nas sugestões abaixo.

<corte>

>
> 2008/7/8 José Mello Júnior <jose.mello.junior@...>:
>> Quando o usuário for dar a sua nota para determinado filme, crie o registro,
>> assim se não houver registro, considere simplesmente que o usuário não deu
>> nota, esta atitude diminuirá substancialemente a quantidade de registros na
>> tabela e trará a necessidade de insert para zero no momento de cadastro do
>> usuário.
>>
>
> José, o problema são os cálculos. A intenção era ter todas as
> entradas, para na hora do cálculo, simplesmente mudar a nota que tinha
> antigamente para a nova nota calculada, e não somar o trabalho de
> calcular notas para diversos filmes e ainda fazer inserções no banco.
> Porém, visto que a inclusão no registro não está dando certo, o jeito
> vai ser repensar isso...
>

Dando meu pitaco:
1. Me parece muito estranho que um usuário dê notas para 11.000 filmes
(principalmente em um sistema web), ele não dá notas apenas para
alguns filmes?

Se as notas forem para um grupo reduzido de filmes considere com
carinho a sugestâo do José Mello Júnior. Para não mudar sua forma de
cálculo creio que a substituição da tabela por uma visão (com OUTER
JOIN) poderia amenizar o problema.

2. Atualmente quando você inclui um novo filme ele deve ser registrado
para cada usário existente? Sem nota?

Em caso afirmativo considere novamente a utilização de visões com
OUTER JOIN.

Osvaldo
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral