2012-03-23 10 views
5

sto usando Symfony 2 con Doctrine come ORM Framework. Sto cercando il modo migliore per salvare le modifiche apportate ai campi del database. Avrò circa 100 tabelle ciascuna con circa 50 campi e alcune migliaia di righe. Ora vorrei salvare tutte le modifiche apportate ai campi.Salva modifiche al campo del database: best practice? Versioning, Loggable?

Possibilità a cui ho pensato: Estensione doctrine "Loggabile": salva le modifiche in una tabella diversa, ma non so se può permettersi questa quantità di voci.

un Trigger MySQL per ogni tabella che salva le modifiche in una nuova tabella?

Ma qual è la procedura migliore per salvare le modifiche?

risposta

5

È possibile utilizzare i trigger MySQL o la funzionalità DoctrineExtension Loggable citata. Entrambe le opere, entrambe hanno contro e pro. Il trigger MySQL può scrivere in una tabella separata (vedere mysql trigger FAQ).

trigger:

  • ++ quadro, linguaggio di programmazione indipendente
  • ++ funziona quando si desidera modificare i dati a mano o da uno script.
  • - È necessario scrivere i trigger per ogni tabella o calcolare una soluzione generica in SQL (non posso fare a meno di farlo).
  • - Se non si ha familiarità con le stored procedure e PL/SQL, beh, c'è la curva di apprendimento

estensioni dottrina:

  • ++ Basta mettere l'annotazione sulle classi e si' fatto.
  • ++ È possibile interrogare la storia, annullare le modifiche tramite l'API Repository
  • - ti blocca a un fornitore, questo a volte è, a volte non è un problema
  • - non funziona quando si modificare i dati a mano o con script di terze parti.

Se la possibilità di passare la dottrina a qualcos'altro è bassa, vorrei iniziare con le estensioni di dottrina. È uno strumento con lo scopo preciso di aiutare a gestire SQL dopo tutto.

0

Una cosa del genere viene comunemente chiamata "modifica acquisizione dati". E 'stato chiesto con riferimento a MySQL prima su SO:

Change Data Capture in MySQL

Forse questa risposta può aiutare.

Diversi fornitori rendono questa funzionalità integrata a vari livelli.

+0

Cercherò di migliorarlo. Certamente la frase "cambia i dati catturati" vale la pena da sola, dal momento che l'OP può prenderlo e correre con esso. – duffymo

1

Suggerirei di utilizzare i trigger, soprattutto se si desidera che la funzionalità di registrazione rimanga indipendente dall'applicazione, ovvero funzionerà anche se si decide di riscrivere l'app su un framework diverso o in un linguaggio di programmazione completamente diverso.

P.S. Non so quanto sia grande il supporto per i trigger in MySQL, dal momento che sono passato a PostgreSQL prima che MySQL li avesse anche loro.