none
Várias tabelas ou poucas tabelas com muitos dados RRS feed

  • Pergunta

  • Boa tarde a todos.

    Gostaria de saber a opinião de vocês. O que degrada mais a performance: ter muitas tabelas com poucas linhas ou ter poucas tabelas com muitas linhas.

    Pergunto isso pois num determinado processo posso criar uma tabela e reaproveitá-la em vários cadastros dentro do sistema ou posso criar uma tabela para cada cadastro. Gostaria de saber qual é a melhor alternativa.

    Sei que isso pode variar de situação para situação. Mas tenho vários cadastros que são parecidos e gostaria de saber se o "reaproveitamento" de tabelas é uma boa opção ou não.

    quarta-feira, 6 de abril de 2011 21:00

Respostas

  • Boa Tarde,

    Aqueles que usam o desempenho como bandeira para justificar todas e qualquer implementação normalmente trabalham em lugares com problemas de desempenho (mesmo depois das implementações).

    Desempenho é muito importante sim, mas não devemos colocar o desempenho em primeiro lugar antes do processo de modelagem. O correto é modelar corretamente e caso a modelagem não atenda, aí sim fazer os ajustes para proporcionar um desempenho aceitável. Até porque nem sempre o desempenho precisa ser conseguido às custas de ajustes na modelagem.

    Dizer que muitas tabelas prejudicam o desempenho do banco é algo no mínimo inventado. Nunca vi nenhum fabricante, estudo ou caso prático de um banco ser prejudicado apenas pela existência de mais tabelas. Isso é algo absolutamente sem sentido. Muitas ou poucas tabelas podem influenciar o desempenho, mas pura e simplesmente por influenciarem a lógica de como uma consulta é realizada e nunca pelo simples fator quantitativo.

    Aproveitar ou reaproveitar é uma questão que não deve ser focada exclusivamente em desempenho. Analise se realmente o reaproveitamento faz sentido. Possivelmente os cadastros terão várias características em comum, mas possivelmente terão muitas características nada em comum. Comparemos por exemplo o cadastro de CDs de um loja com o cadastro de verduras e frutas de uma feira. CDs, verduras e frutas certamente tem um nome, uma unidade de medida e um preço, mas com certeza um CD vai ter milhares de características que um verdura ou uma fruta não terá. Se você compartilhar o cadastro em comum apenas por reaproveitar, pode preparar-se para milhares de registros nulos e vários IFs na hora dos INSERTs e aí sim você pode ter não só problemas de desempenho, mas também de consistência.

    Por outro lado, compartilhar um cadastro de CDs e de DVDs de música na mesma tabela pode ser interessante. Não são a mesma coisa, pois, o CD é universal enquanto o DVD tem regiões de aceitação, mas na grande maioria, as características do dois são equivalentes.

    Alguns links para você refletir a respeito:

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte I
    http://gustavomaiaaguiar.wordpress.com/2009/11/10/a-impedancia-o-mapeamento-objeto-relacional-e-implementacoes-%E2%80%93-parte-i/

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte II
    http://gustavomaiaaguiar.wordpress.com/2009/11/15/a-impedancia-o-mapeamento-objeto-relacional-e-implementacoes-%E2%80%93-parte-ii/

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte III
    http://gustavomaiaaguiar.wordpress.com/2010/01/04/a-impedancia-o-mapeamento-objeto-relacional-e-implementacoes-%E2%80%93-parte-iii/

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    • Sugerido como Resposta Gustavo Maia Aguiar quarta-feira, 6 de abril de 2011 22:29
    • Marcado como Resposta Eder Costa sexta-feira, 8 de abril de 2011 18:45
    quarta-feira, 6 de abril de 2011 22:29
  • Boa tarde Eduardo,

     

    Como você disse, depende muito da sua situação, das consultas mais frequentes nessa(s) tabela(s). 

    Se você dividir em várias tabelas, terá que fazer JOIN entre elas? Ou a consulta sempre será individual, uma tabela por vez?

    Se as consultas não forem individuais e você tiver que fazer JOIN entre as tabelas, na minha opinião não compensa dividir em várias e sim fazer uma só, desde que você faça uma boa análise de índices e até faça o particionamento (dependendo do tamanho que essa tabela vai ficar).

     

    Espero ter ajudado.

     

    Abraço

     


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */
    • Marcado como Resposta Eder Costa sexta-feira, 8 de abril de 2011 18:45
    quarta-feira, 6 de abril de 2011 21:28

Todas as Respostas

  • Boa tarde Eduardo,

     

    Como você disse, depende muito da sua situação, das consultas mais frequentes nessa(s) tabela(s). 

    Se você dividir em várias tabelas, terá que fazer JOIN entre elas? Ou a consulta sempre será individual, uma tabela por vez?

    Se as consultas não forem individuais e você tiver que fazer JOIN entre as tabelas, na minha opinião não compensa dividir em várias e sim fazer uma só, desde que você faça uma boa análise de índices e até faça o particionamento (dependendo do tamanho que essa tabela vai ficar).

     

    Espero ter ajudado.

     

    Abraço

     


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */
    • Marcado como Resposta Eder Costa sexta-feira, 8 de abril de 2011 18:45
    quarta-feira, 6 de abril de 2011 21:28
  • Mariana, antes de mais nada, obrigado pela resposta.

    São tabelas simples que terão poucas linhas e também não seria necessário fazer JOIN no caso que apresentei. Se fosse analisar olhando apenas essa situação eu não teria qualquer problema com performance, independente de ser uma tabela ou várias.

    Mas um DBA que trabalhou aqui na empresa disse uma vez que criar muitas tabelas no banco de dados não é algo interessante e que pode prejudicar a performance. Aí veio a dúvida: isso é realmente verdade? Nunca encontrei nada a respeito.

    Com isso criou-se a cultura de reaproveitamento de tabelas. Sinceramente não gosto desse reaproveitamento e por isso pergunto de maneira geral se ter muitas tabelas no banco de dados pode realmente fazer a performance do banco cair.

    quarta-feira, 6 de abril de 2011 22:10
  • Eduardo, de uma olhada no link abaixo, sobre normalização de banco de dados.

    http://www.luis.blog.br/normalizacao-de-dados-e-as-formas-normais.aspx

     


    Abraço

    Estevam

    **** Se a reposta foi útil, então não esqueça de marca-lá. ***
    quarta-feira, 6 de abril de 2011 22:12
  • Boa Tarde,

    Aqueles que usam o desempenho como bandeira para justificar todas e qualquer implementação normalmente trabalham em lugares com problemas de desempenho (mesmo depois das implementações).

    Desempenho é muito importante sim, mas não devemos colocar o desempenho em primeiro lugar antes do processo de modelagem. O correto é modelar corretamente e caso a modelagem não atenda, aí sim fazer os ajustes para proporcionar um desempenho aceitável. Até porque nem sempre o desempenho precisa ser conseguido às custas de ajustes na modelagem.

    Dizer que muitas tabelas prejudicam o desempenho do banco é algo no mínimo inventado. Nunca vi nenhum fabricante, estudo ou caso prático de um banco ser prejudicado apenas pela existência de mais tabelas. Isso é algo absolutamente sem sentido. Muitas ou poucas tabelas podem influenciar o desempenho, mas pura e simplesmente por influenciarem a lógica de como uma consulta é realizada e nunca pelo simples fator quantitativo.

    Aproveitar ou reaproveitar é uma questão que não deve ser focada exclusivamente em desempenho. Analise se realmente o reaproveitamento faz sentido. Possivelmente os cadastros terão várias características em comum, mas possivelmente terão muitas características nada em comum. Comparemos por exemplo o cadastro de CDs de um loja com o cadastro de verduras e frutas de uma feira. CDs, verduras e frutas certamente tem um nome, uma unidade de medida e um preço, mas com certeza um CD vai ter milhares de características que um verdura ou uma fruta não terá. Se você compartilhar o cadastro em comum apenas por reaproveitar, pode preparar-se para milhares de registros nulos e vários IFs na hora dos INSERTs e aí sim você pode ter não só problemas de desempenho, mas também de consistência.

    Por outro lado, compartilhar um cadastro de CDs e de DVDs de música na mesma tabela pode ser interessante. Não são a mesma coisa, pois, o CD é universal enquanto o DVD tem regiões de aceitação, mas na grande maioria, as características do dois são equivalentes.

    Alguns links para você refletir a respeito:

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte I
    http://gustavomaiaaguiar.wordpress.com/2009/11/10/a-impedancia-o-mapeamento-objeto-relacional-e-implementacoes-%E2%80%93-parte-i/

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte II
    http://gustavomaiaaguiar.wordpress.com/2009/11/15/a-impedancia-o-mapeamento-objeto-relacional-e-implementacoes-%E2%80%93-parte-ii/

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte III
    http://gustavomaiaaguiar.wordpress.com/2010/01/04/a-impedancia-o-mapeamento-objeto-relacional-e-implementacoes-%E2%80%93-parte-iii/

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.wordpress.com


    Classifique as respostas. O seu feedback é imprescindível
    • Sugerido como Resposta Gustavo Maia Aguiar quarta-feira, 6 de abril de 2011 22:29
    • Marcado como Resposta Eder Costa sexta-feira, 8 de abril de 2011 18:45
    quarta-feira, 6 de abril de 2011 22:29