Início / dba / Perguntas / 461
Accepted
Gabriel Solomon
Asked: 2011-01-11 01:30:20 +0800 CST

Coluna duplicada para consultas mais rápidas?

  • 772

O título não faz muito sentido, mas não consegui pensar em um título melhor para esse problema.

tenho as seguintes tabelas

Projetos

  • Eu iria
  • nome

Clientes

  • Eu iria
  • id_project
  • nome

Pagamentos

  • Eu iria
  • id_cliente
  • encontro
  • soma

Quando um usuário entra no sistema, ele terá acesso a um determinado projeto. Agora, quero listar todos os pagamentos desse projeto e deve ser bem fácil:

SELECT FROM payments where id_customer in (SELECT id from customers where id_project = 5)

Minha dúvida é: se não for melhor adicionar uma coluna id_project na tabela de pagamentos assim as consultas ficarão mais fáceis e rápidas.

database-design normalization

3 respostas

  1. Best Answer

    Parece que você está perguntando se a desnormalização faz sentido.

    A desnormalização é o processo de tentar otimizar o desempenho de leitura de um banco de dados adicionando dados redundantes ou agrupando dados. Em alguns casos, a desnormalização ajuda a encobrir as ineficiências inerentes ao software de banco de dados relacional. Um banco de dados relacional normalizado impõe uma carga pesada de acesso sobre o armazenamento físico de dados, mesmo que esteja bem ajustado para alto desempenho.

    A resposta é sempre "depende", então aqui está minha regra de ouro:

    Se ...

    • a quantidade de dados não é grande
    • você não está fazendo uma tonelada de junções já
    • e/ou o desempenho do banco de dados não é atualmente um gargalo

    então fique normalizado . Sim, a desnormalização é mais rápida, mas também significa que você tem dados redundantes no sistema - dados que devem ser mantidos e sincronizados. Não há mais "uma fonte" para esses dados, mas várias fontes que podem se desviar. Isso é arriscado ao longo do tempo, portanto, você não deve fazê-lo, a menos que tenha boas razões para fazê-lo, apoiados por alguns benchmarks.

    Eu só desnormalizaria quando...

    • a quantidade de dados é muito grande
    • junções são caras e você tem que fazer muitas delas para obter consultas triviais retornadas
    • o desempenho do banco de dados é um gargalo e/ou você deseja ir o mais rápido possível

    As junções são muito rápidas em hardware moderno, mas nunca são gratuitas.

    • 64

  2. Seria melhor reescrever a consulta como:

    SELECT payments.*
FROM   customers
JOIN   payments 
ON     payments.id_customer = customers.id
WHERE  customers.id_project = 5

    Embora isso pareça menos conciso e um bom planejador de consulta veja o que você está tentando fazer e execute sua subconsulta correlacionada como a junção acima, um planejador de consulta ruim pode acabar fazendo uma varredura de índice payments.id_customer(supondo que você tenha um índice relevante ) (ou pior, digitalização de tabela) em vez de fazer as coisas da maneira mais eficiente. Até mesmo um bom planejador de consulta pode não conseguir ver a otimização se o arranjo dessa consulta estiver envolvido em algo mais complicado. Expressar o relacionamento como uma junção em vez de uma subconsulta pode fazer mais diferença do que alterar sua estrutura de dados.

    Como diz Jeff, qualquer desnormalização deve ser considerada com cuidado - ela pode trazer aumentos de desempenho fáceis, especialmente para alguns fins de relatório, mas pode levar a inconsistência devido a bugs na lógica de negócios de suporte.

    Como nota lateral: obviamente não conheço o seu negócio, então posso estar perdendo alguma coisa, mas seus relacionamentos na mesa parecem estranhos para mim. Eles implicam que você nunca pode ter mais de um projeto com o mesmo cliente, o que geralmente não é verdade em minha experiência, pelo menos por um longo período.

    customer     project      payment
--------     --------     -------
                          pa_id
             pr_id    <-- payment
cu_id    <-- customer

    ou se for menos normalizado (embora eu duvide que isso seja necessário):

    customer     project      payment
--------     --------     --------
                          pa_id
             pr_id    <-- payment
cu_id    <-- customer 
           `------------- customer

    Claro que ainda desconta a possibilidade de um projeto conjunto com dois clientes...

    • 10

  3. Em alguns bancos de dados você tem a possibilidade de criar "Visões materializadas" em vez de VISÕES complexas com uma grande quantidade de dados, com base em uma consulta complexa. Isso pode ser usado para evitar a desnormalização em um sistema de aplicativo com crescimento histórico. Se você decidir usar " Visualizações Materializadas" você deve ter uma ideia clara dos métodos de atualização e a quantidade de armazenamento que será usado pela Visualização Materializada...

    • 6

relate perguntas