Controllo modifiche database - Parte o astratta da ORM / Application Layer?

Question

Controllo modifiche database - Parte o astratta da ORM / Application Layer?

#1 da (2 voti)
#2 da (2 voti)

6

I miei colleghi sviluppatori e io siamo a un bivio nel modo di continuare a controllare i cambiamenti del database.

La maggior parte delle nostre applicazioni registra le modifiche tramite INSERT , UPDATE e DELETE trigger.

Alcune delle nostre più recenti verifiche delle applicazioni a livello ORM; in particolare utilizzando Hibernate Envers .

Sebbene il controllo dei livelli ORM fornisca un'interfaccia più pulita ed è molto più gestibile, non acquisirà alcuna modifica manuale del database. Il controllo del livello ORM significa anche che le nostre librerie richiedono attualmente una dipendenza dalla nostra implementazione ORM a meno che, in particolare nel nostro caso, ad esempio, JPA pianifichi di fornire qualcosa nel prossimo futuro.

Esiste un paradigma comune che risolve questo problema?

database logging orm

posta BrandonV 03.10.2012 - 17:19

fonte

2 risposte

2

C'è un paradigma che risolve questo problema. Si chiama "trigger".

Se ci sono più persone e sistemi in grado di toccare i dati al di fuori del controllo del codice, il codice non può registrare tali modifiche. Ne hai bisogno in uno strato vicino ai dati in modo che non venga ignorato.

Questa è una violazione dei livelli? Può essere. Ma lo sono anche le chiavi primarie e quelle straniere. Applicano le cose a uno strato vicino ai dati che potrebbero teoricamente essere applicati esclusivamente dal codice. Mantieni una mente aperta e non seguire un particolare metodo di progettazione come vangelo.

risposta data 05.10.2012 - 02:27

fonte

Leggi altre domande sui tag database logging orm

Qual è il modo migliore per avvicinarsi ai progetti di visualizzazione? Come devo gestire un reindirizzamento a un provider di identità durante una richiesta di dati API web

score 2 · Accepted Answer

ORM layer auditing also means that our libraries will currently require a dependency on our ORM implementation unless

È giusto. vuoi tutta la tua logica aziendale in un unico posto, inclusa la registrazione.

it will not capture any manual database changes that are made

A meno che tu non abbia registrato manualmente le modifiche ... Se stai bene inserendo manualmente le voci dei dati (ignorando il tuo livello aziendale) non vedo alcun motivo per cui creare voci di registro manuali ti infastidirebbe.

Infine, c'è la possibilità di duplicare la logica nel Trigger. Avere un campo che cattura la fonte dei dati, in modo da sapere quali voci sono state fatte manualmente (e da chi) e quali erano dall'app. (Questa è una buona idea indipendentemente dal tuo problema di registrazione). In questo modo è possibile codificare il trigger per attivare solo gli aggiornamenti manuali. (Questa è una soluzione orribile ... Ma è fattibile)