Lavorando da Redmine e dalla sua progettazione di database hai un ticket, un articolo di giornale e qualsiasi dettaglio associato a questo.
+--------------+ +----------------+ +----------------+
| ticket | | journal | | journal_details|
|--------------| |----------------| |----------------|
| id +-+ | id +-+ | id |
| author | +---+ ticket_id | +-+ journal_id |
| subject | | author | | field |
| priority | | timestamp | | new_value |
| ... | | notes | | old_value |
| | | | | |
+--------------+ +----------------+ +----------------+
Non copi l'intero problema ogni volta, ma conservi tutte le informazioni relative a "intestazione" e metadati aggiornate nella tabella ticket .
Quindi, per gli aggiornamenti (note aggiuntive e qualsiasi modifica di campo), si crea una riga nella tabella del journal. Se tutto ciò che hai fatto è stato aggiungere note, basta aggiungere una voce di diario. Se, tuttavia, un campo è cambiato (come la priorità), viene aggiunta una riga di registrazione a giornale e una riga journal_detail per ogni riga modificata.
Supponiamo che tu abbia il biglietto # 123 e tu:
- Aggiungi note ('questa è in realtà la barra')
- Cambia l'oggetto da "foo" a "bar"
- Modifica la priorità da "critico" a "basso"
Le seguenti cose accadono:
- La riga del diario viene aggiunta con l'autore come te, data / ora come ora, ticket_id come 123 e le note come "questa è effettivamente la barra". Diciamo che questa riga ha un ID di 456.
- Una riga journal_detail viene aggiunta con jounral_id di 456, campo di 'subject' new_value di 'bar', old_value di 'foo'
- Una riga journal_detail viene aggiunta con journal_id di 456, campo di 'priority' nuovo valore di 'low', vecchio valore di 'critical'
- Il ticket viene aggiornato con oggetto di 'bar' e priorità di 'basso'
In questo modo, se necessario, è possibile ricostruire il passato e vedere chi ha fatto cosa quando. Ma poche persone vogliono vedere cosa veramente assomiglia a un mese fa - vogliono query e display veloci rispetto ai dati attuali.