Sto lavorando a un sistema di ordini e all'implementazione di un registro di controllo. Due preoccupazioni principali sono:
1) Durante il controllo di un elemento pubblicitario, dovresti visualizzare solo i controlli per l'elemento pubblicitario
2) Durante il controllo di un ordine, dovresti visualizzare controlli relativi alle informazioni dell'intestazione E all'elemento pubblicitario.
Ad esempio, un elemento pubblicitario avrebbe una traccia di controllo per ciò che è stato modificato nei campi dell'elemento pubblicitario, inoltre sarebbe stato registrato anche qualsiasi aggiunta / rimozione / modifica a commenti, foto allegate, ecc.
Un controllo per un ordine dovrebbe contenere tutte le cose di cui sopra, più le modifiche all'ordine effettivo (cambi di posizione di spedizione, modifiche al nome dell'acquirente, ecc.)
Invece di rispecchiare le relazioni per le tabelle di audit trail, sto pensando di avere solo 2 tabelle, che sono come seguite
Audit_Log:
-audit log id
-entity type
-entity id
-audit timestamp
-audit user
-audit message (serialization of object changes most likely)
Audit_Relationship
-audit log id 1
-audit log id 2
-is child of entity
Ciò richiederà semplicemente query e ordinamento di audit trail. Un grande vantaggio è che tutte le tracce di controllo sono in una tabella. Puoi semplicemente ordinare per data e ora e avere un'idea di cosa sta succedendo esattamente nel sistema (anche se, penso che i controlli siano intesi principalmente a concentrarsi su un'area più piccola, cioè un ordine specifico, per vedere i cambiamenti).
Qualcuno ha provato un design simile? Sono preoccupato se questo confonde le relazioni tra entità. Ad esempio, un controllo dei commenti a lungo per un elemento pubblicitario verrà associato a un ordine, anche se tale relazione non esiste nella logica di business. Il "è figlio dell'entità" è stato utilizzato per rendere questo un po 'più chiaro. ..
* Sto usando php con Doctrine 2, ma penso che sia un'idea abbastanza astratta per lavorare con qualsiasi ORM.
** (AGGIUNTO) Sto anche usando MySQL e considerando l'uso dei trigger di database piuttosto che farlo a livello di libreria ORM.
** (AGGIUNTO) L'utilizzo del metodo descritto sopra potrebbe essere una pessima idea. Quando si collega una pista di controllo, è necessario ottenere tutte le entità che saranno associate alla pista di controllo. Per fare ciò avremmo bisogno di implementare un metodo per ottenere una lista di ID effettivi. Forse alcune annotazioni speciali utilizzate da Doctrine per capire quali proprietà dovrebbero essere seguite quando il log di controllo sta "ribollendo" e allegando?
In ogni caso, passare a tempi di lettura più lunghi usando i join sembra molto più ragionevole di un tempo di scrittura più lungo per questa funzione.