Come si decide tra inserire il codice nel database o inserire il codice nell'applicazione? [chiuso]

Otterrete due scuole di pensiero: stored procedure e nessuna stored procedure. Sono nel campo che il database è solo per contenere i miei dati, il mio programma è per analizzare e usare quei dati. Con l'avvento di Entity Framework, spinge maggiormente l'enfasi sul lato codice (secondo me).

Se utilizzi le stored procedure, hai due luoghi in cui cercare un potenziale bug: il tuo codice e / o la tua Stored procedure.

È sempre consigliabile mantenere la logica del database all'interno del database. Il motivo è perché l'astrazione dei dettagli del datastore sottostante deve essere resa opaca all'applicazione.

Se la struttura del database cambia, è necessario modificare i proc, le funzioni e le viste memorizzati. Ma tu non vuoi che l'applicazione si interrompa da nessuna piccola alla maggior parte delle principali modifiche al database.

Il motore del database, tramite l'uso di stored procedure, memorizza nella cache anche i piani di esecuzione anche se i valori dei parametri cambiano.

La separazione logica dovrebbe essere separata il più possibile, e questo è tutto parte dell'architettura a più livelli.

Lascia la logica del database al database.

I fattori principali per la mia mente:

• Lo sviluppatore che lo programmerà avrà più competenza nella lingua del database o nella lingua dell'applicazione?
• Quanto è caricato il server del database rispetto al server che esegue l'applicazione?
• Quanto codice è attualmente presente in entrambi i moduli?

Se il server DB si sta abituando così pesantemente che potrebbe verificarsi del timeout nell'esecuzione della stored procedure, potrebbe essere meglio farlo nell'applicazione. Allo stesso modo, se lo sviluppatore ha una vasta esperienza sull'uno o sull'altro, allora può avere senso in quanto potrebbe essere usato per sviluppare abilità nel lato più debole o sfruttare il lato più strong a seconda del modo in cui si vuole valorizzare il lato positivo di ciascuna opzione.

Il problema con l'inserimento del codice all'interno del database è che il linguaggio di programmazione del database non è molto buono, in relazione a ciò in cui scrivi la logica di business. Diciamo che dopo un po 'vuoi supportare più tipi di ammortamenti basati su il tipo di contratto e che alcuni contratti sono basati su tassi variabili calcolati come formule definite in modo diverso dal contratto individuale con le variabili nelle formule di tasso che fanno riferimento a tabelle di tassi come LIBOR. Ora immagina che vengano lanciate più valute. Ora immagina che alcuni contratti calcolino gli interessi il primo giorno lavorativo del mese in base al calendario delle festività del paese in cui è scritto il contratto ...

Ovviamente, YAGNI probabilmente coprirà tutti i miei esempi, ma il punto è che ci sono molti requisiti aziendali che potrebbero farti desiderare di spostare la logica di business dal database e in un linguaggio più potente . Ovviamente, è possibile applicare YAGNI e tenerlo in una stored procedure ora, ma c'è una maggiore possibilità che si sposterà sul livello aziendale di quanto non lo sia nel suo spostamento nel database se si avvia nel livello aziendale, come regola generale.

Questo è il tipo di cosa che può essere una chiamata difficile, ma è qualcosa da tenere a mente nel tuo caso particolare.

Qui ci sono due filosofie in competizione:

Se si posizionano tutte le logiche di business per il calcolo dei pagamenti nell'applicazione, è necessario che eventuali ulteriori esigenze dell'applicazione (desktop, web, smartphone, piattaforme di modifica, servizio Web, altri database, ecc.) siano necessarie codice duplicato. Ci scontriamo ora con il mio lavoro con due applicazioni che accedono agli stessi database, eseguono alcune delle stesse operazioni, ma non sempre fanno affidamento sul codice del database semplificato.

Se il database fa i calcoli, allora deve essere fatto solo in un posto. Qualsiasi applicazione può connettersi al database, chiamare la stored procedure e ottenere gli stessi risultati. Non avrai mai due dirigenti che sostengono che i loro rapporti stiano dando i numeri giusti, o che la casa di qualcuno venga preclusa perché una app mostra che hanno interrotto i pagamenti e un'altra mostra che stanno pagando il prezzo eccessivo.

La mia opinione è che la logica di business dovrebbe essere fatta il più possibile nel database, ma se non è possibile, assicurati di metterla in un posto solo e non dividerla tra il database e l'applicazione.

Non c'è una risposta giusta per questo.

Le stored procedure saranno più facili da aggiornare se c'è un bug, basta aggiornare la procedura, non è necessario creare un codice. Con il codice sarebbe necessaria una build se c'è un bug.

Se cambi mai i tuoi dati di back-end (da Oracle a SQl Server o viceversa), il codice dovrà essere trasferito, con il codice la logica rimarrà intatta e potrà essere portata, a patto che la piattaforma rimanga la stessa.

Con il codice, dovrebbe essere più facile e meno complesso progettare un programmatore di ammortamento estendibile. Se i calcoli cambiano dal client, l'estensibilità sarebbe un obiettivo di progettazione. Le procedure memorizzate sono in qualche modo monolitiche, quindi il codice sarebbe una scelta migliore. Con una procedura memorizzata ho potuto vedere che diventa complicato se sono richiesti diversi tipi di calcoli.

Se l'azienda dice che il calcolo è lo stesso, non importa quale, mi piacerebbe che mi riferissi a una procedura memorizzata, se ci fossero differenze future, l'avrei messo in codice e reso estensibile.

Tipi di calcoli. Nel tuo esempio, non credo che i database svolgano un buon lavoro in questo tipo di attività come farebbe un programma procedurale.

Codice di condivisione. Potrebbero esserci limitazioni su come la codifica può essere condivisa. Se stai scrivendo un codice personalizzato per tutte le applicazioni, hai qualsiasi formato riutilizzabile che desideri. Alcune applicazioni di terze parti o qualsiasi app in cui non si controlla il codice e gli scrittori di report potrebbero richiedere l'utilizzo di una stored procedure o qualche altro tipo di oggetto di database.

Diffondere il lavoro tra i membri del team. Mettere il codice nello stesso posto ed essere coerenti è grande, a meno che tu non abbia uno staff di due persone e uno di loro sia nell'area di competenza del database, senso di dividere il lavoro per utilizzare le ore uomo.

Diffusione del lavoro tra hardware. Questo ha davvero senso solo se sono in corso processi batch lenghtly. Ciò farebbe impazzire gli sviluppatori che cercano di bilanciare le attività casuali tra app e server di database. È più probabile che aumenti l'hardware su uno o l'altro e inserisci tutto il tuo codice lì.

Competenza degli sviluppatori Gli sviluppatori hanno preferenze basate probabilmente sulla competenza. Lo codifichi dove pensi che sia più facile. Certo, stai cercando di lavorare all'interno dei parametri dell'applicazione, ma se hai la possibilità di scegliere ...

La prima cosa che devi chiederti è quanto ti preoccupi dell'accuratezza e della correttezza del calcolo mentre viene registrato nel database.

Se il denaro o i requisiti legali sulla privacy sono sulla linea, non è possibile affidarsi all'applicazione con il calcolo. O il database deve eseguire il calcolo, o preferibilmente, un livello intermedio di logica aziendale in esecuzione in una stanza chiusa sotto il tuo controllo.

Il problema è che non puoi fidarti dei dati provenienti da un client esterno ! Se qualcuno può fare soldi mentendo al tuo database ci sono buone probabilità che lo facciano. Se potessi ottenere un mutuo da $ 500.000 all'1% semplicemente riportando il numero sbagliato nel tuo database, allora ho una strong motivazione a farlo. Per quel tipo di denaro potrebbe valere la pena di eseguire l'applicazione con un debugger mentre si osserva il traffico tra le applicazioni e il database con gli sniffer di rete. Alla fine imparerò come impersonare la tua applicazione e manderò il database un numero a mia scelta.

Se non ti interessa davvero l'integrità del calcolo e nessuno può trarre alcun vantaggio mentendo sul calcolo, non devi preoccuparti così tanto. Puoi decidere in base al ragionamento che altre persone hanno offerto.

EDIT: permettimi di aggiungere un paio di esempi specifici in cui non ti dovresti fidare di un calcolo proveniente dal client.

1. Convalida della sicurezza. Per quanto sciocco possa sembrare, questo torna sui siti web di volta in volta. Il controllo della password viene eseguito in Javascript incorporato oppure l'utente viene convalidato una volta controllando con il database e il risultato della convalida viene memorizzato in un cookie o come parametro nell'URL. Non scherzo, ci sono stati siti web che sono stati violati semplicemente cambiando un parametro URL da? IsAuthenticated="F" a? IsAuthenticated="T".

2. Calcoli di bonus / commissioni. Supponiamo che tu abbia un'applicazione utilizzata dalla forza vendita in cui inseriscono le loro vendite e il loro bonus è calcolato. Se il database registra semplicemente il bonus o la commissione come presentato dall'applicazione, quindi un addetto alle vendite con un background tecnico potrebbe utilizzare un debugger per gonfiare le sue commissioni. Il database o il livello intermedio deve almeno verificare la validità del calcolo e quindi si duplica il codice per il calcolo nel database e nell'applicazione.