Importanza delle stored procedure e dei trigger nella creazione di applicazioni Web? [duplicare]

Well I have seen other developers who used them but only when they were the only solution.

Le stored procedure e le query sono mai la unica soluzione. Nessuno ti obbliga a rafforzare la coerenza nel database. Diavolo, non devi nemmeno usare il database in primo luogo. Oppure puoi usarne uno che non ha alcuna funzione.

Ma ci sono molte situazioni in cui forniscono alcuni vantaggi utili:

1. Sicurezza. Molti motori di database possono concedere l'autorizzazione per eseguire una stored procedure senza concedere autorizzazioni generali alle tabelle sottostanti. Ancor di più usando i trigger per scrivere i record della cronologia (ciò che è stato modificato quando e da chi, chiamato anche audit trail) ha il grande vantaggio che anche se l'applicazione è compromessa, gli hacker non saranno in grado di disabilitare la registrazione.

2. Regole di coerenza complicate. A volte si hanno vincoli di integrità utili che non possono essere espressi da semplici chiavi esterne, vincoli univoci e simili. È ora di controllarli con il trigger.

3. Coerenza tra più applicazioni. Quando hai una query complessa che deve essere eseguita in modo coerente da diversi client, puoi inserirla nella stored procedure.

4. Schermatura di più client dalle modifiche nello schema. Se il database è accessibile da più client, se è necessario modificare lo schema per uno di essi, le stored procedure e le viste possono nascondere le modifiche agli altri in modo da non doverli aggiornare immediatamente.

Esistono tuttavia alcuni svantaggi, in particolare per le stored procedure:

1. Rendono il codice difficile da capire. Per comprendere il codice che elabora una query è necessario conoscere la query e la query raramente ha senso senza il codice che la circonda. Per schemi molto complessi, a volte è possibile aggiungere un livello più semplice di viste e stored procedure, ma evitare assolutamente la politica di mettere tutto nelle stored procedure.

2. Sono dolorose il retro della versione. Il codice dell'applicazione di versioning è ben gestito, ma la gestione dello schema del database richiede la scrittura di molti script di aggiornamento e alcuni macchinari per applicarli o molto lavoro manuale soggetto a errori. Poiché i trigger e le stored procedure sono soggetti anche a questo, molti di essi aumentano il lavoro.

Mi piace utilizzare le stored procedure quando si utilizza MSSQL, poiché in MSSQL è possibile assegnare autorizzazioni utente solo alla stored procedure. La mia limitata esperienza con MySQL e Postgres mostra che le stored procedure sono ancora una buona pratica, ma le autorizzazioni devono sempre essere concesse sulle tabelle utilizzate dalla procedura.

Fondamentalmente, io uso le stored procedure per separare la sintassi SQL dal progetto stesso. Sai, sbarazzati di tutte le istruzioni SELECT nel codice. È anche più semplice modificare una stored procedure piuttosto che individuare l'istruzione SQL corretta nel codice.

Per quanto riguarda i trigger, li stiamo abusando al concerto attuale per registrare i dati su insert e aggiornare le tabelle di log (politica aziendale, non la mia idea). Altrimenti, consiglierei di stare lontano da loro, a meno che non siano assolutamente necessari.