[firebase-br] RES: Tabelas....

Rodrigo Cury cury.fb em gmail.com
Ter Dez 8 20:50:15 -03 2009


atualmente utilizamos DATASETS onde são feitas as consultas em todas
as sete tabelas e inserem no dataset!.
´exatamente isso que eu acho que dá trabalho...

tive pesquisando, talvez seria interessante fazer uma VIEW fazendo
consulta em todas as tabelas!!



Em 08/12/09, Felix<felix2005 em oi.com.br> escreveu:
> Fiquei na duvida: um select ira ser feito a partir da composição de todas as
> tabelas? OU os selects irão ter visão de cada tabela separadamente?
>
>
> Fco. Felix
> Desenvolvimento de Sistemas
> www.soltecnologia.com.br
>
> -----Mensagem original-----
> De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
> nome de Eduardo Jedliczka
> Enviada em: segunda-feira, 7 de dezembro de 2009 21:23
> Para: FireBase
> Assunto: Re: [firebase-br] Tabelas....
>
> uma tabela com 10 milhões de registros não terá problemas de perfomance
> para inserts e selects (como o índice provavelmente terá profundidade 4,
> ele será ligeiramente mais lento do que  um índice de 800 mil registros)
>
> talvez você tenha problemas nos updates e deletes (se eles ocorrerem em
> grande volume, ou melhor em muita concorrência) por culpa dos page
> locks...
>
> Apesar de que, se o sistema for bem estruturado, uma tabela de 20
> milhões de registros não requer um impacto absurdamente grande no banco.
>
> mas, veja bem, se as tabelas são similares (mesmas FKs, mesmos
> relacionamentos, ets) e não ferir nenhuma forma normal, talvez seja uma
> boa juntar... simplifica o sistema, mas se há excessões.... deixe
> separado.
>
> abraço
>
> Eduardo
>
>
> Em Seg, 2009-12-07 às 17:17 -0300, Rodrigo Cury escreveu:
>
>> Boa tarde a todos.
>>
>> Eu queria que vocês dessem a opinião de vocês num discussão que tive
>> recentemente com um colega de trabalho com relação a tabelas,
>> registros, índices etc.
>>
>>     A discussão foi devido a uma discordância com relação a um caso no
>> nosso sistema. Utilizamos atualmente 7 tabelas de grupos diferentes
>> com estruturas muito parecidas (no máximo 5 campos diferentes) entre
>> elas. Eu defendo a 'teoria' de que as 7 tabelas deveriam ser 1 só para
>> facilitar a codificação, considerando que cada vez que há alteração na
>> estrutura de dados, lá vamos nós alterando todas as 7 tabelas, todas
>> as 7 entidades, todos os 7 tudo a fora no sistema. Porém ele defende a
>> teoria que as tabelas devem ser separadas pelo fato de que existem 7
>> índices e 23 chaves estrangeiras entre elas, e nelas são
>> frequentemente feitas bem mais inserções, alterações do que pesquisas
>> e que o volume de registros ultrapassam os 10.000.000 (dez milhões).
>> Segundo ele esses fatos fazem com que o banco fique lento para
>> inserções, alterações e pesquisas se fosse uma tabela só.
>>
>>     Então o que vocês acham??? Deixa as tabelas separadas por que o
>> banco fica lento
>>     ou junta tudo numa só pra facilitar a programação???
>>     Porque??
>>
>>
>> Muito obrigado pela opinião de todos!
>>
>> ______________________________________________
>> 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://firebase.com.br/pesquisa
>
>
> ______________________________________________
> 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://firebase.com.br/pesquisa
>
>
> ______________________________________________
> 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://firebase.com.br/pesquisa
>




Mais detalhes sobre a lista de discussão lista