[firebase-br] OFF TOPIC - Sugestão de modelagem

Ter Set 1 08:11:12 -03 2015

Bom dia.
Obrigado pelas respostas Rafael e Gladiston.

Gladiston, de fato acho que deu a entender que estava tercerizando o
trabalho, mas não era minha intenção hehe já tenho definido como fazer, mas
como você disse apenas queria expor para ter uma  luz sobre pontos que não
havia pensado.

Obrigado mais uma vez.

Abraço,
Renan Rogowski Pozzo

*"E a paz de Deus, que excede todo o entendimento, guardará os vossos
corações e os vossos pensamentos em Cristo Jesus." Filipenses 4.7*

Em 31 de agosto de 2015 17:02, Gladiston Santana <gladiston em vidy.com.br>
escreveu:

> Creio que esteja pensando na modelagem por causa da performance, que
> dependendo da modelagem poderá ficar mais lento ou mais rapido, é isso?
> Se for, tente entender como os índices funcionam para fazer uma modelagem
> de acordo.
> Dá uma lida aqui:
> http://www.ufjf.br/jairo_souza/files/2012/11/CFLP_O028.pdf
> Lá cita como exemplo, um sistema de followup, talvez uma idéia semelhante a
> sua:
> "Todos devem saber que uma tabela de “follow-up's” cresce assustadoramente
> de
> tamanho e que em geral são divididos em duas etapas : agendar follow-ups
> (insert)
> e realizar follow-ups(update). Se ambas as etapas forem armazenadas numa
> única
> tabela, o que ocorreria ?
> Vejamos...relatórios e consultas de follow-up em geral são feitas de tudo
> quanto é
> maneira : pesquisa por data, atendente, cliente, .... então deveríamos ter
> vários
> índices associados a tabela de follow-up, certo?
> Mas com tantos índices associados à tabela de follow-up, o que ocorreria
> com os
> agendamentos, que são basicamente inserts ? Também ficariam lentos, pois
> para
> cada INSERT todos os índices associados a tabela de followups precisariam
> também ser atualizados.
> Então nesse caso, separar em duas tabelas diferentes e para cada tabela os
> seus
> respectivos índices seria a melhor maneira, e com o uso de uma "view"
> (visão)
> poderíamos ver ambas as tabelas como se fossem apenas uma.
> Percebeu? Usando a racionalidade num banco de dados, o que podemos chamar
> de "normatização", todos os problemas fazem parte de uma lógica a ser
> resolvida
> que determinará ou não a divisão de tabelas."
>
>
> Tome muito cuidado com opiniões, ninguém aqui conhece seu sistema ou o
> ambiente que será usado, não é que pedir opinião está errado, é que você
> deveria solicitá-la para confirmar a decisão que já tinha em mente ou
> trazer a luz pontos que não havia pensado. Da forma como postou dá entender
> que você está terceirizando à lista o que irá fazer depois.
>
> Um abraço e sucesso.
>
> Em 31 de agosto de 2015 14:06, Renan Rogowski Pozzo <renanrpozzo em gmail.com
> >
> escreveu:
>
> > Boa tarde.
> > Gostaria de uma sugestão quanto a modelagem dos dados, se os colegas
> > puderem me ajudar.
> >
> > Vou ter uma tabela de POSTS, e alguns posts terão data de agendamento
> para
> > publicação. A cada 10 posts 1 deles terá, mais ou menos.
> >
> > Nesse caso, é vantagem ter uma nova tabela acessória para armazenar essa
> > data, ou criar os campos na tabela POSTS? Quais as vantagens e
> desvantagens
> > de fazer de uma forma ou de outra?
> >
> > Agradeço a ajuda.
> >
> > Abraço,
> > Renan Rogowski Pozzo
> >
> > *"E a paz de Deus, que excede todo o entendimento, guardará os vossos
> > corações e os vossos pensamentos em Cristo Jesus." Filipenses 4.7*
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > Para saber como gerenciar/excluir seu cadastro na lista, use:
> > http://www.firebase.com.br/fb/artigo.php?id=1107
> > Para consultar mensagens antigas:
> > http://www.firebase.com.br/pesquisa_lista.html
> >
>
>
>
> --
> --
> B em B@BU     iB em M@B.  B em MBBO   MBBMMB em B@BZLr    E@@@@i      r@@@BU
> vB em M@O     E em B@Bu   BBBM em 0   G em MMM@N8MBB em ZP5r  B em B@k      8B@@O
>  OB em B@q   2 em BBBM    B em B@BO   BB em B@B,.:,7B em B@@L uB em B@,    OB em B@.
>  ,@@@B@   @BBB@,    @BBB em 8   M em M@@@     PB em B@B  @@@BN   iB em B@L
>   U em B@B2 LB em B@X     B em MBBO   MBBM em B     i em BBB@. 7 em B@Bi  B em B@E
>    B@@@BiM em M@B.     @BBM em G   M em MMB@     v@@M em B,  G em B@Z v em B@B.
>    7B em B@O em B@B5      B em B@B8   BBBM em B     Z@@@B@   iB@@@2 em B@Br
>     NB em M@B em B8       @B em B@8   M em B@B em i:i75 em B@B em r    E@@B em B@Bq
>     . em B@@@B@:       B em B@B@   @B@@@B em B@B@@@ME;     .BB em MBB@
>      55.ANOS        OMOGBS   PBZGGOOMOO117,        7 em BBB@r
>      ==============================================r@@@@F=====
>      Gladiston Santana                             8 em B@B,
>      Supervisor de TI                             G em B@B7
>      Tel.:+551147873122 R:228                    :@B em B0
>      Grupo VIDY - SGQ ISO9001 - 55 ANOS          @B em B@.
>      Visite nosso site: www·vidy·com·br         BB@@@u
>      Visite também : www·expolabor·com·br      GB em B@N
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas:
> http://www.firebase.com.br/pesquisa_lista.html
>