Database: dove dovrebbe essere eseguita la logica dell'applicazione? [duplicare]

Rispondere alla mia domanda (aggregando tutto ciò che ho letto fino ad ora):

• Separazione delle preoccupazioni
  • Implementa la logica di business nell'applicazione in modo che tragga vantaggio dal più ricco ambiente di sviluppo, testing e debug offerto al di fuori del banca dati.
  • L'integrità dei dati e le preoccupazioni trasversali (ad es. controllo, reporting) devono risiedere nel database .
  • I database hanno bisogno di un livello di astrazione per evitare la duplicazione del codice e consente di aggiornare rapidamente le istruzioni SQL quando lo schema viene modificato. Il livello di astrazione può risiedere nell'applicazione o nel database.
• Prestazioni
  • Le istruzioni preparate sono veloci come le stored procedure.
  • Il sovraccarico della rete è trascurabile , a meno che non sia necessario trasferire grandi quantità di dati dal server al client e viceversa .
• Sicurezza
  • Le stored procedure non sono più sicure degli attacchi dinamici di SQL for injection
  • Le stored procedure consentono di concedere le autorizzazioni in termini di metodi API invece del livello tabella / vista . Ad esempio, anziché "I clienti dovrebbero essere autorizzati a visualizzare la tabella Account e aggiornare la tabella Balance " hai "I clienti dovrebbero essere autorizzati a invocare TransferFunds() ". Dovresti essere in grado di emulare lo stesso schema di autorizzazione utilizzando le visualizzazioni .
• Casi d'uso comuni
  • Se il database deve supportare più applicazioni, il livello di astrazione dovrebbe probabilmente risiedere nel database sotto forma di stored procedure . Questo è most frequentemente citato use-case di DBA per l'implementazione della logica nel database.
  • Se l'applicazione deve supportare più database, il livello di astrazione dovrebbe probabilmente risiedere nel livello applicazione .
• Varie
  • I tuoi sviluppatori dovrebbero essere esperti in SQL. Imparare la lingua è molto più facile di quanto pensi. Non ingannare te stesso: gli sviluppatori che cercano di evitare SQL produrranno problemi di scalabilità.

Riepilogo : contrariamente a quanto si crede, non è consigliabile utilizzare stored procedure per motivi di prestazioni o sicurezza. dovresti utilizzarli per supportare più applicazioni, rafforzare l'integrità dei dati e implementare problemi trasversali che non possono essere facilmente implementati nel livello dell'applicazione.

Sentiti libero di spingere tutta la logica rimanente nel livello applicazione.

La scalabilità non è l'unico problema nel fare questa scelta (e so di database di successo con migliaia di miliardi di record, quindi i database sono più scalabili di quanto si pensi). Né è probabilmente il più importante.

Per prima cosa devi controllare il significato dei dati. Qualcosa come Facebook è legato intrinsecamente alla sua applicazione e quindi mettere la logica non è rischioso come un'applicazione aziendale che deve ottenere i suoi dati da importazioni, lavori di database, inserimento di dati da diverse applicazioni tra cui alcune che forse l'azienda ha nessun controllo. Quindi il rischio per l'integrità dei dati è la prima e più importante cosa da considerare quando si effettua questa scelta.

Inoltre, come verranno utilizzati i dati e in quale ambiente è critico. Come vengono controllate le informazioni? Ci sono requisiti normativi? Come viene eseguita la segnalazione? Devo essere in grado di riutilizzare la logica in un sistema di reporting diverso così come nell'applicazione utente? In tal caso, la logica deve riposare all'esterno dell'applicazione. Devo fare le esportazioni dei dati e come è influenzato dalla logica nell'applicazione. Ciò significa che le persone che scrivono il report e il codice di esportazione non avranno la possibilità di vedere quale sia la logica perché non hanno accesso al codice dell'applicazione? Questo può essere un grosso problema.

Un'altra considerazione è la scalabilità che include le prestazioni. Di quanta scalabilità hai bisogno? Pochissime cose hanno bisogno della scalabilità di un Facebook. Di quante prestazioni hai bisogno? Progettare per la scalabilità quando non ne avrai mai bisogno porta a risultati non ottimali. I metodi utilizzati per inserire la logica nell'applicazione avranno un impatto negativo sulle prestazioni del database (molti ORM, ad esempio, scrivono codice di database terribile).

Poi c'è l'argomento su meno tempo per lo sviluppo che è ridicolo. Se sai cosa stai facendo, inserire la logica nel database non richiede più tempo di metterlo nell'applicazione. È solo che la maggior parte degli sviluppatori di applicazioni non sono specialisti SQL. Tuttavia, il risparmio del tempo di sviluppo per migliorare SQL è davvero un vantaggio? No, non è perché questa scelta ha quasi sempre un costo di prestazioni sul database e al costo dell'integrità dei dati.

Quello che sto cercando di dire è che non esiste una taglia adatta a tutti. Ci sono alcune applicazioni in cui la logica nell'applicazione ha senso e altre no, ma pensare che ci siano solo uno o due fattori critici da considerare quando si effettua la scelta è generalmente un errore.

Tendo a raccomandare / preferire:

• Accesso

  • Livello dell'app per logica applicativa ("cancella utente", "cambia password", "aggiungi cliente").
  • Per conformità / controllo, applicare direttamente al database (poiché questo catturerà qualsiasi altro mezzo di accesso indiretto, come gli amministratori di database)

• Sicurezza / Autorizzazioni

  • La sicurezza dovrebbe essere implementata all'interno dell'applicazione.
  • All'interno del DBRMS, la sicurezza può essere implementata in una dozzina di modi diversi (amministratori SQL, spesso amministratori locali sono amministratori SQL (non che dovrebbero essere), proprietario DB, ruoli DB, diritti oggetto) ... questo può facilmente portare a confusione ("chi ha i diritti per X?", "come fa Jane Doe ad avere il permesso per Y?") ... evitare dove possibile. E i diritti direttamente al DB possono essere pericolosi, dal momento che ci sono tanti strumenti per accedere ai database (Excel, Access, ecc.) ... troppo facile per gli utenti per colpire direttamente il DB e fare cose che ignorano il processo dell'app.
  • Ammettiamolo, la maggior parte delle app NON usa l'autenticazione integrata (NTLM / Kerberos). WebApp richiede Kerberos, che è fastidioso e confuso per molti, in più significa che le autorizzazioni all'interno del DB possono causare problemi all'app (se, ad esempio, l'app non sa come gestire quando una determinata chiamata fallisce a causa dell'utente essere nel gruppo corretto) ... inoltre, ci sono troppi modi per applicare le autorizzazioni direttamente a SQL, per imporre una buona coerenza ... INOLTRE, le app non eseguiranno la scansione del DB per tali errate configurazioni ("Accidenti, l'utente può eseguire le cose perché sono SA, quando in realtà dovrebbero essere un membro di questo ruolo DB ").
  • (MSSQL) I ruoli delle applicazioni sono usati raramente, ma DOVREBBE ESSERE (guardando gli sviluppatori qui). Ottimo modo per rafforzare le autorizzazioni delle app all'interno di SQL.

• Query

  • query semplici (SELECT *, SELECT by ID) possono essere gestite da ORM che scrivono SQL dinamico
  • Le query complesse tendono a essere scritte meglio a mano, quindi scrivi uno sproc e una mappa all'interno di ORM

• INS / UPD / DEL

  • nessuna preferenza specifica.
  • da un lato, il passaggio di un oggetto app a uno sproc rende la transazione INS / UPD più semplice tra le tabelle
  • d'altra parte, il ridimensionamento può significare che alcune tabelle vengono spostate su altri server, quindi le transazioni non sono contenute in un singolo server
  • Inoltre, il blocco delle transazioni richiede l'ottimizzazione per garantire che i blocchi non diventino ostacoli alle prestazioni. Il modello alternativo "NOSQL" / "consistenza finale" è ad alte prestazioni, ma richiede più codice e più sysadmin (poiché di solito ci sono più sistemi coinvolti per tracciare e propagare i dati tra i database / server cache).

• SDL

  • dovrebbe essere eseguito solo durante la distribuzione ... presumibilmente un processo di installazione / aggiornamento esegue il codice SDL

Bene, c'è la risposta pratica, e poi c'è questa.

La domanda è intitolata "Dove dovrebbe essere eseguita la logica dell'applicazione?" Ma se ci pensi, questo confonde due cose che dovrebbero essere separabili:

• Come dovrebbe la logica dell'applicazione essere coded ?
• Dove dovrebbe essere la logica dell'applicazione eseguire ?

Una delle grandi debolezze, non generalmente riconosciute, della tecnologia dei database di oggi è che fare una scelta per una di queste domande di solito costringe la mano a un'altra:

• Se si sceglie di eseguire la logica dell'applicazione sul database, si è obbligati a utilizzare il linguaggio procedurale del database (eeek, PL / SQL) o il supporto davvero ingombrante per le procedure memorizzate in lingua di terze parti.
• Se si sceglie di codificare la logica dell'applicazione in un buon linguaggio di programmazione, si perdono i vantaggi dell'integrità dei dati a meno che non si duplichi lo sforzo e si codifichi parte della stessa logica anche nel database.

Ma idealmente, dovrei essere in grado di codificare tutta la mia logica di applicazione una volta , in un potente linguaggio di programmazione di mia scelta e se la logica viene eseguita sull'applicazione o il database dovrebbe essere un ritardo - decisione vincolata che scelgo quando distribuisco l'applicazione o anche fino al runtime.

Infatti, idealmente dovrei essere in grado di eseguire la stessa logica contemporaneamente nel browser, nel server delle applicazioni e nel database. Pensa alle regole di convalida in un'applicazione web basata su moduli. Idealmente, si desidera che la logica di convalida venga eseguita su tutti e tre i livelli:

1. Il browser deve eseguire la logica di convalida, in quanto può fornire all'utente un feedback di latenza molto basso quando riempie il modulo in modo errato. Inoltre, impedendo all'utente di inviare moduli non validi, riduce il carico sui livelli inferiori.
2. Il server delle applicazioni deve eseguire la logica di convalida, perché non può fidarsi del browser per farlo: un hacker può aggirare la logica del browser. Inoltre, recuperando i moduli non validi prima che vengano inviati al database, riduce il carico su quella risorsa condivisa fondamentale.
3. Il database deve eseguire la logica di convalida, poiché è responsabile dell'applicazione di integrità dei dati per più utenti dei dati.

Quindi davvero vorresti codificare una volta quella logica e avere strumenti che la applicano in tutti e tre i posti. Ma esiste una piccola e preziosa tecnologia per raggiungere questo obiettivo.