costano compromessi per la distribuzione delle modifiche a prod, stored procs vs. LINQ

Question

costano compromessi per la distribuzione delle modifiche a prod, stored procs vs. LINQ

#1 da (11 voti)
#2 da (2 voti)
#3 da (0 voti)

4

Un contesto per questa domanda: non si tratta del tempo di sviluppo sull'iterazione di sviluppo intera , ma solo dello stadio di distribuzione delle modifiche dall'ambiente di sviluppo a quello di produzione. "LINQ" qui significa veramente LINQ, ORM o C # in cui sarebbe altrimenti usato T-SQL. E qui "stored proc" è solo un termine generico che comprende oggetti di database che includono processi, funzioni e viste memorizzati. La domanda è stata appena formulata come "LINQ", "stored procs" poiché i due vengono comunemente confrontati nelle domande. Per restringere la portata della discussione possiamo assumere le applicazioni web. Ora finalmente la domanda è,

Quali sono i trade-off nel costo di implementazione (da dev a prod) tra i due approcci?

Alcuni dicono che è più facile eseguire il rollback delle modifiche dello schema Db rispetto alle modifiche di rollback su file C # in una soluzione. Altri dicono che è più semplice la versione o il codice C # di controllo sorgente rispetto agli oggetti schema Db. Se apporti modifiche alle query LINQ, molto probabilmente dovrai ricompilare l'app per spingere le modifiche a prod. Se apporti modifiche allo schema del database, potrebbe essere necessario eseguire uno script T-SQL per sincronizzare le modifiche a prod.

Come per molte decisioni con la programmazione, la soluzione scelta potrebbe essere sensibile al contesto. per esempio. per le strutture dati alcune situazioni possono richiedere una mappa hash e, per altre, potrebbe essere meglio usare uno stack. Ognuno ha i suoi vantaggi / svantaggi.

version-control development-process database

posta T. Webster 07.01.2012 - 07:14

fonte

3 risposte

Leggi altre domande sui tag version-control development-process database

Java ha una gestione automatica della memoria? Come raggiungere il livello avanzato in SQL? [chiuso]

score 11 · Answer 1

Stai facendo la domanda sbagliata, non si tratta di costo si tratta di RISCHIO .

Modifiche al codice del database ripple verso l'alto e verso l'esterno dove il codice non del database cambia (Application Logic) ripple verso il basso e verso l'interno . Ciò significa che le modifiche apportate a ripple verso l'alto e verso l'esterno saranno sempre risker .

Modifica una procedura memorizzata , funzione , tabella o vincolo o qualcosa di veramente e puoi facilmente rompere ogni applicazione che utilizza tale database senza alcun modo per conoscere la portata completa di ciò che sarà interessato. Dovresti ottenere ogni applicazione che tocchi il database al test di regressione, e affrontarlo, nel mondo reale solo facendo test Unit molto meno completi Test di integrazione è una cosa rara.

Ecco un esempio reale che mostra che il costo è determinato dal rischio . Questo è solo un esempio, ogni situazione sarà diversa.

A well meaning DBA reordered some columns of a table when doing some other un-related work that was requested. It completely broke a bunch of apps silently that had SELECT * queries and referred to the returned fields by index, since all the columns were mapped to String types, the application slowly and silently corrupted tonnes of data as data was read and re-written to the database in the wrong locations.

Questo è successo veramente, ho dovuto ripulire il casino personalmente. All'epoca ero un appaltatore di armi a noleggio, quindi ho avuto il noioso lavoro di sistemare il codice rotto e scrivere programmi di pulizia per riordinare i dati. Immagina quanto costa !

Se invece si modifica la logica dell'applicazione, l'unica cosa che interessa direttamente è l'applicazione su cui si sta lavorando. (Escluso fare qualcosa che corrompe i dati nel database e altre cose stupide, che possono essere testisticamente testati).

I più rischiosi saranno sempre gli ordini di magnatitudine più costosi da correggere quando esploderà in produzione.

Il tuo costo è determinato da più rischioso ?

score 2 · Answer 2

Nel 2012, direi che sono uguali, presumendo che tu abbia un modo solido di implementare le migrazioni di database e le solide procedure di implementazione. Se hai a che fare con la distribuzione di modifiche al database, che non si compilano ma sono parte integrante del codice sorgente, si assumono gli stessi costi generali del tempo che si tratti di una soluzione basata su ORM o di una soluzione basata su RPC (le procedure memorizzate sono chiamate di procedura remota).

In genere, le modifiche al codice sono più pulite e facili da implementare e in particolare per il rollback della produzione. Il peggior scenario è quello di far cadere l'app per 5 secondi per sostituire i file e farli ruotare. Aggiornamenti dello schema del database, o anche ripristini peggiori, possono essere brutti affari. A seconda della scala, i tempi di inattività possono misurare le ore.

score 0 · Answer 3

La tua domanda implica che una nuova funzione della tua app web possa essere implementata tramite modifiche ai proc memorizzati o tramite modifiche all'app. Per la mia esperienza, questo è molto raro. Molto spesso hai

basta scambiare l'app (e mantenere il database così com'è)
o scambia l'app e cambia il db

Ovviamente il secondo passo richiede più sforzo del primo.

L'unica eccezione è rappresentata dal fatto che l'app è progettata appositamente per l'esecuzione generica di query o stored proc, in cui le query stesse sono considerate una forma di dati, tra l'utente o l'app può scegliere in modo dinamico quale eseguire hai in mente un'architettura del genere?