Application Logic Vs Trigger DB per la pulizia del database

Question

Application Logic Vs Trigger DB per la pulizia del database

#1 da (5 voti)
#2 da (3 voti)
#3 da (1 voti)

4

Quando si puliscono i vecchi dati da una serie di tabelle di database, è più sicuro avere la logica nell'applicazione o nel trigger di un database?

Sto aggiornando un'applicazione che ho scritto qualche istante prima (e in modo affrettato) e una delle cose che voglio pulire prima è garantire che i dati che non vengono più utilizzati vengano eliminati in modo efficace. Attualmente questo viene fatto nella mia applicazione stessa attraverso un numero di chiamate SQL a varie tabelle. Alcune di queste query richiedono un po 'di tempo per essere eseguite e poiché l'applicazione è basata su PHP, non voglio che gli utenti debbano attendere troppo a lungo.

Stavo quindi pensando di creare un trigger del database su una tabella che pulisse allegramente tutte le altre tabelle e quindi consentissi l'eliminazione della singola riga dalla mia tabella principale.

Sto prendendo in considerazione questi pro e contro al momento:

Trigger del database
(+) invisibile all'applicazione
(+) Semplifica la logica dell'applicazione - i nuovi oggetti possono essere semplificati
(-) Aggiunge complessità alla manutenzione generale - devono mantenere codice e trigger durante le modifiche alla tabella, ecc.
Logica dell'applicazione
(+) Mantiene tutte le attività di manutenzione in un unico punto
(-) Caricamenti di pagina più lunghi su determinate attività
(-) Più possibilità di temporizzazione di una richiesta - dati orfani

Se hai ulteriori informazioni, considerazioni a cui non ho pensato qui, fai esperienza con l'una o l'altra o puoi indicarmi qualche lettura sull'argomento, mi piacerebbe sentirla.

Modifica: originariamente pensavo che le mie pagine sarebbero più veloci, ma se creo un trigger Prima di eliminare , la pagina verrà caricata allo stesso modo - come nell'applicazione invia una piccola query ma non verrà eseguito fino a quando non verrà completata l'intera serie di istruzioni nel trigger?

php mysql application-design database-design

posta Fluffeh 03.08.2012 - 05:44

fonte

3 risposte

3

Se hai una sola applicazione che ha accesso in scrittura al tuo database (o almeno alle tabelle rilevanti qui), e le tue operazioni CRUD sono in una posizione di quella applicazione, di solito non c'è bisogno di usare i trigger per mantenere i tuoi dati coerenti. I trigger sono una buona cosa quando non sai in anticipo chi e quali processi / applicazioni accederanno al tuo DB in futuro, e vuoi mantenere un sacco di regole di coerenza in un unico posto, principalmente nel tuo DB. Quindi, la mia "regola generale":

quando hai l'unica applicazione che scrive l'accesso al tuo DB sotto il tuo controllo, metti la logica db (come le regole di cancellazione) completamente nella tua applicazione, a causa di una manutenzione più semplice
quando il DB manterrà i suoi dati coerenti da solo, perché hai un numero crescente di applicazioni sviluppate da un gruppo di persone e non puoi assicurare che ogni sviluppatore di quel team comprenda tutte le regole di coerenza di ogni parte del tuo database, quindi utilizzi trigger

E come hai visto tu stesso, la performance può o non può influenzare la tua decisione, ma spesso le differenze sono trascurabili e i colli di bottiglia possono comunque essere risolti in modo diverso.

risposta data 03.08.2012 - 20:13

fonte

1

È possibile utilizzare ON DELETE CASCADE ma richiedere molto tempo se si dispone di molti record figlio. Molti dbas non ti permetteranno di usarlo poiché può bloccare il sistema. Personalmente, se gli utenti vogliono vedere i dati scomparsi immediatamente, vorrei usare un campo flag is_deleted sulla tabella genitore (con una vista che mostra solo i non cancellati) e quindi eliminare realmente i record nei batch durante i tempi di non-produzione .

risposta data 03.08.2012 - 19:58

fonte

Leggi altre domande sui tag php mysql application-design database-design

Chi è il proprietario del codice, a chi appartiene l'algoritmo, a chi appartiene l'idea? TDD in JavaScript [chiuso]

score 5 · Accepted Answer

Nel caso dell'archiviazione o dell'eliminazione di dati obsoleti o obsoleti, prendere in considerazione una terza opzione, ovvero un lavoro batch pianificato, che rileva e cancella i vecchi dati. Il lavoro potrebbe quindi essere pianificato, ad es. una volta al giorno in un periodo relativamente tranquillo, con un impatto minimo sulla tua applicazione. Il lavoro potrebbe essere parte di altri lavori di database standard, ad es. OTTIMIZZA / reindicando ecc.

L'unica eccezione potrebbe essere se. per esempio. stai aggiornando 2 tabelle con una relazione 1: many (ad esempio, Fattura e InvoiceLineItem), per cui hai deciso di eliminare tutti gli elementi pubblicitari della fattura esistenti prima di inserirne di nuovi. Poiché la cancellazione è deterministica (sai esattamente cosa devi eliminare) e perché vuoi anche che la cancellazione faccia parte di una transazione più grande che include gli inserimenti successivi, allora direi che questo sarebbe un buon candidato per l'applicazione tier.

Tuttavia, non riesco a vedere lo scopo di fare questo in un trigger - questo potrebbe causare inutili perdite di prestazioni per i tuoi inserti / aggiornamenti mentre il tuo trigger cerca dati obsoleti, e quindi blocca file non correlati altrove dopo averli cancellati.