Devo eseguire i calcoli in T-SQL o programma?

Preferisco mantenere un sacco (non tutto , ma in abbondanza) della logica nel database solo per un sacco di motivi (e senza entrare nell'argomento "chi ha bisogno di stored procedure oggigiorno") .

Fai questo nello stored procedure.

Sembrano semplici calcoli. Usa anche una transazione nel tuo sproc per gestire le scritture su entrambe le tabelle, a meno che non vada bene se il tuo database diventa incoerente (a volte la scrittura potrebbe avere successo in una tabella, ma non nell'altra). E non ascoltare i ragazzi che cercano di dirti che "i veri programmatori scrivono il loro codice di rollback", perché è semplicemente sciocco. :-) L'unico codice di rollback affidabile è il codice di rollback all'interno del motore del database stesso ed è facile da usare.

Se esegui questi calcoli nel tuo codice imperativo all'esterno del database e utilizzi due stored procedure per scrivere i dati, devi ancora prendere in considerazione l'utilizzo di una transazione di database a meno che non sia corretto per il tuo database diventare incoerente. Quindi ora (se lo fai fuori dal database) all'improvviso hai almeno 4 chiamate di andata e ritorno nel database anziché 1:

1. Inizia TX
2. Scrivi tabella 1
3. Scrivi tabella 2
4. Esegui TX

Se le scritture sono piccole, è del tutto possibile che si verificheranno ulteriori sovraccarichi nei round trip della rete rispetto al lavoro effettivo svolto dal database. Anche se è possibile utilizzare la stessa connessione per chiamare entrambe le stored procedure (necessario, se si utilizza una transazione), è comunque necessario effettuare più chiamate separate al server del database attraverso la rete.

Infine, se la logica dei calcoli cambia, e stai facendo quei calcoli nel tuo codice al di fuori del database, allora devi cambiare quel codice, ricompilarlo e ridistribuire il programma aggiornato. Ma se si dispone di quei calcoli nella stored procedure, è possibile ricostruire quella stored procedure senza dover ridistribuire (reinstallare?) L'intera applicazione.

Tutti questi punti sono esacerbati se parliamo di un'app desktop client spessa, che non hai specificato, perché ciò significa che devi reinstallare l'app aggiornata su ogni workstation e, mentre lo hai installato su alcune workstation ma non su altre, hai diverse workstation che fanno cose diverse al tuo database. Inoltre, a seconda del controllo del codice sorgente e delle pratiche di compilazione, è possibile esaminare un'operazione importante per tornare indietro nel tempo e diramare il repository per apportare alcune modifiche al livello di accesso ai dati, per non parlare del potenziale lavoro necessario per unire le modifiche in il ramo in avanti nel DAL nella tua linea di origine principale.

Fai questo nello stored procedure, perché è onestamente il posto giusto per farlo.

Preferisco mantenere il database al di fuori il più possibile. In questo modo, se il modo in cui vengono eseguiti i calcoli viene modificato, ho solo bisogno di aggiornare il codice nel programma e non scherzare con le stored procedure.

Non sono sicuro di quanto siano complessi questi calcoli, ma se diventano un collo di bottiglia puoi sempre spostarli da qualche altra parte.

Mi sembra che questi semplici calcoli dovrebbero essere fatti come parte del report e non devono essere memorizzati in una tabella di reporting. Ciò offre la flessibilità di consentire il cambiamento dei calcoli e di non dover ricreare i dati nella tabella di reporting.

La responsabilità principale del motore di database è quella di archiviare i dati e di estrarli quando ne abbiamo bisogno.

Dovremmo mettere la nostra logica aziendale / manipolazione con i dati nel codice del programma. In modo che non dipenda dal database. Può essere unità testabile. Meglio in termini di prestazioni. Possiamo utilizzare l'intero concetto OOP nella nostra logica aziendale.