Design de banco de dados - Pergunta sobre eficiência (e qualidade geral do projeto)

Question

Receio não saber o que estou fazendo.

1:

Eu tenho uma mesa chamada ticket que tem uma coluna chamada total. Quando o total é atualizado, quero manter um registro dele (total antigo, etc.), então decidi remover o total coluna e crie uma tabela chamada ticket_total com colunas ticket_id, total, e datetime (O mais recente, é claro, é o total "atual").

ou

2:

Então eu percebi que mais tarde vou querer dar aos meus clientes a capacidade de classificar os ingressos por total, ou puxar relatos que agregam os totais, etc. Então, decidi, em vez disso, colocar de volta o total coluna on ticket, e para mudar o total coluna diretamente quando o total é atualizado, mas primeiro crie um ticket_total linha como um registro do anterior total.

Parece que a versão 2 seria altamente eficiente porque eu não precisaria consultar o relacionado ticket_total Tabela tanto, mas eu me pergunto o que vocês gurus de DB pensam por aí. Estou apenas aprendendo o design e o medo do banco de dados que nunca vou ser bom nisso.

Answer 1

Eu iria com a opção 2 que você sugeriu.

Apenas certifique -se de que você esteja fazendo a atualização (do ticket) + inserção (em ticket_total) em uma transação para garantir que a integridade seja mantida.

Answer 2

Sua segunda alternativa é mais rápida, mas se você deseja criar relatórios sobre valores históricos do total, deve ter uma tabela separada, onde você armazena o valor que está substituindo junto com um registro de data e hora. Este tipo de tabela é referido como um Tabela de auditoria.

Answer 3

Re: "Eficiência" - O melhor é não se preocupar muito com a eficiência do banco de dados no início de um projeto. A otimização prematura é um erro comum a ser evitado.

Melhor é focar em suas necessidades e projetos para eles. Mais tarde, você pode testar se estão os gargalos de desempenho e trabalhar para resolvê -los.

Para bancos de dados menores (dezenas de milhares de linhas), mesmo as consultas "ineficientes" geralmente se tornam muito rápidas, considerando os servidores e o software de hoje.

Mantenha simples Sugiro que você evite teclas de combinação e semântica da tabela de sobrecarga, a menos que você realmente tenha a necessidade.

Proposta Você tem dois tipos de dados: informações atuais do ticket e uma tabela de histórico para valores "totais" antigos.

Portanto, seu ver 2 seria preferido.

ticket
  id
  field_a
  field_b
  total    # current_total

ticket_total  # history of ticket total field
  id
  ticket_id
  total
  create_time

Também "Total" parece uma agregação de algo. Eu sugiro que você tente criar um nome de campo mais descritivo. - Qual é o campo um total? "Total_Worktime"?

Adicionado Lembre -se de adicionar índices para as tabelas. ÍNDICE por qualquer coisa que você usa para achados. Por exemplo, a tabela de ingressos tem um cliente_id? Certifique -se de que esteja indexado.

Answer 4

Eu faria Ticket_total uma visualização, não uma tabela. Eu criaria outra visualização Ticket_Current, onde filtraria os tickets até a última data, ou seja, se a tabela de ingressos for com teclado duplo em Ticket_id e DateTime. Caso contrário, desconsidere essa última parte.