Acompanhamento de alterações em postagens

5

Atualmente, estou escrevendo um sistema de tickets de suporte ... Digamos que seja um aplicativo de fórum pequeno ou algo como Uservoice.

Agora, quero que meus usuários possam editar os tickets, mas ainda possam ver as versões antigas deles.

Qual caminho devo seguir em termos de design de banco de dados?

Eu pensei em algo como:

SupportTickets

  • Identificador
  • Autor
  • Assunto
  • SupportTicketContentId

SupportTicketContents

  • Identificador
  • Conteúdo
  • CreatedOn

Agora, ao visualizar um ticket, basta consultar o SupportTicketContent mais recente, dependendo da coluna CreatedOn ...

Mas existe uma maneira melhor? Ou há uma melhor nomeação dessas tabelas?

    
por SeToY 13.08.2013 / 16:39
fonte

2 respostas

2

Trabalhando em Redmine e no design de seu banco de dados, você tem um ticket, um item de diário e quaisquer detalhes associados a ele.

 +--------------+     +----------------+   +----------------+
 | ticket       |     | journal        |   | journal_details|
 |--------------|     |----------------|   |----------------|
 | id           +-+   | id             +-+ | id             |
 | author       | +---+ ticket_id      | +-+ journal_id     |
 | subject      |     | author         |   | field          |
 | priority     |     | timestamp      |   | new_value      |
 | ...          |     | notes          |   | old_value      |
 |              |     |                |   |                |
 +--------------+     +----------------+   +----------------+

Você não copia todo o problema toda vez, mas mantém todas as informações de 'cabeçalho' e metadados atualizadas na tabela ticket .

Em seguida, para atualizações (anotações adicionais e alterações de campo), você cria uma linha na tabela do diário. Se tudo o que você fez foi adicionar anotações, basta adicionar uma entrada de diário. Se, no entanto, um campo for alterado (como a prioridade), uma linha de entrada de diário será adicionada e uma linha de journal_detail para cada linha será alterada.

Digamos que você tenha o bilhete # 123 e você:

  • Adicionar notas ("isso é realmente uma barra")
  • Alterar o assunto de 'foo' para 'bar'
  • Altere a prioridade de "crítica" para "baixa"

As seguintes coisas aconteceriam:

  • A linha do diário é adicionada ao autor como você, timestamp como agora, ticket_id como 123 e as notas como 'this is actually bar'. Vamos dizer que esta linha tem um ID de 456.
  • Uma linha journal_detail é adicionada com jounral_id de 456, campo de 'subject' new_value de 'bar', old_value de 'foo'
  • Uma linha journal_detail é adicionada com o journal_id de 456, campo de 'priority' novo valor de 'low', valor antigo de 'critical'
  • O ticket é atualizado com o assunto "bar" e a prioridade de "baixo"

Desta forma, se necessário, pode-se reconstruir o passado e ver quem fez o quê quando. Mas poucas pessoas querem ver o que realmente parece há um mês - elas querem consultas rápidas e exibições em relação aos dados atuais.

    
por 13.08.2013 / 17:01
fonte
0

Resposta curta: Honestamente, criar um novo sistema de rastreamento de tickets a partir do zero é tentador e legal! No entanto, eu tentaria ficar longe de reinventar a roda.

Uma das boas abordagens seria esclarecer todos os requisitos de negócios e procurar alternativas de código aberto disponíveis. Aqui estão várias alternativas para começar:

por 13.08.2013 / 16:57
fonte