Il mio dipartimento è specializzato nella conversione dei dati dei clienti nel nostro schema di database in modo che possano utilizzare il nostro software.

In questo momento, abbiamo applicazioni C # che richiedono un IDataReader(99% delle volte a SqlDataReader), eseguono operazioni di pulizia e mappatura, lo inseriscono in un DataRowoggetto e quindi usano a SqlBulkCopyper inserirlo nel nostro database.

A volte (specialmente quando il database di origine contiene immagini come varbinaryoggetti), questo processo può davvero impantanarsi con un trasferimento SQL dal server all'app, per poi girare a destra e tornare al server.

Sento che se riscrivessimo alcune delle conversioni come pacchetti SSIS, questo potrebbe accelerare molto le cose. Tuttavia, il più grande muro di pietra in cui continuo a correre è quando il mio capo, in modalità Non inventato qui , fa un passo indietro e dice "Cosa succede se Microsoft lascia cadere il supporto per SSIS? Avremo tutto questo codice obsoleto e saremo fregati".

Questa non è la prima volta che premo "Cosa succede se rimuovono quella funzione ...?" risposta dal mio capo. Non ho il tempo di scrivere la conversione alla vecchia maniera, autodidatta a me stesso SSIS e anche di scriverla nel nuovo modo di dimostrare / testare i benefici (Nessuno di noi ha usato SSIS quindi ci sarebbe un periodo in cui vorremmo imparare a usarlo).

Cosa dovrei fare in questa situazione? Smetti di spingere la nuova tecnologia? Aspetta che lasci il dipartimento (io sono la seconda persona più anziana nel dipartimento dopo di lui, ma potrebbero passare anni prima che esca / si ritiri)? Trova un nuovo modo per convincerlo a smettere di aver paura degli strumenti di terze parti?

Ci penserò da un punto di vista gestionale, ma tieni presente che sono consapevole di non avere tutti i dettagli. Riassumo ciò che vedo:

1. Sviluppatore di medio livello, lo chiameremo "Scott", raccomanda una riscrittura del codice legacy in SSIS per migliorare le prestazioni di importanti processi ProcessA.
2. ProcessA si sta attualmente comportando in uno stato funzionante senza problemi importanti noti.
3. ProcessA è scritto con strumenti proprietari che utilizzano conoscenze comuni o potenzialmente tribali da mantenere.
4. La raccomandazione di riscrivere richiederà nuovi strumenti per supportare.
5. Il personale attuale non ha esperienza / conoscenza documentata con i nuovi strumenti.
6. I nuovi strumenti sono sostituzioni relativamente recenti con strumenti meno recenti e il supporto per questi strumenti può cambiare ragionevolmente entro 4 trimestri aziendali.

Da questo punto di vista, tutto ciò che vedo è un grande esborso di denaro da parte dell'azienda per migliorare un processo che non è rotto . Da un punto di vista tecnico posso vedere l'appello, ma quando ci si arriva fino in fondo, non ha senso per il business apportare questo cambiamento. Se si disponesse di personale con esperienza documentata con SSIS e parametri di riferimento per mostrare un notevole miglioramento di questo processo (tenere presente, il miglioramento massiccio DEVE equivalere a $$$), il risultato potrebbe essere leggermente diverso. Allo stato attuale, però, dovrei essere d'accordo con la direzione (da qualche parte un albero è appena morto).

Se si desidera favorire l'adozione di SSIS e potenzialmente condurre a questo refattore, è necessario acquisire questa esperienza e formazione con progetti più piccoli e meno importanti. Fornire parametri di riferimento e supporto per SSIS e assicurarsi che tutta l'infrastruttura e il supporto siano attivi prima che la direzione prenderà in considerazione la possibilità di apportare le modifiche. Una volta che hai lo strumento in uso altrove, le persone del team hanno sperimentato il suo utilizzo e un fattore "comfort" aziendale che il supporto non cambierà e sradicherà tutto, avrai più probabilità di influenzare qualcuno al tuo punto di vista. Senza quelli, stai abbaiando l'albero sbagliato con quell'argomento.

Per quanto sembri stupido, a volte il modo "migliore" non è il modo migliore.

Modifica: in risposta ad alcuni aggiornamenti alla domanda, posterò una leggera modifica alla mia risposta.

Se il processo presenta difficoltà di qualche tipo, riscriverlo sarà comunque un'impresa costosa. Si consiglia di considerare quale sarebbe il costo della messa a punto del codice esistente rispetto alla riscrittura del pacchetto. Considera gli impatti non solo sul software ma su tutti i processi di interfacciamento umano. Quando si tenta di ottenere un buy-in da parte della direzione per una riscrittura, si ridurrà sempre in fondo. A meno che tu non possa dimostrare che l'attuale disagio costa ora denaro o diventerà grande nel complesso, la direzione non vedrà ancora il vantaggio. Questo costo potrebbe non essere necessariamente di natura finanziaria. Se il rallentamento compromette un sistema che causa tempi di inattività, introduce vettori di intrusione o qualche altro sintomo "difficile da quantificare", potrebbe essere necessario trovare un modo per tradurre quel problema in un equivalente di rischio monetario. Un vettore di intrusione, ad esempio, può provocare un'intrusione che può comportare la perdita, il furto o il danneggiamento dei dati. La società potrebbe perdere la reputazione o fallire un controllo di sicurezza necessario. La chiave è far sì che il manager in questione riconosca i vantaggi quantificabili della modifica.

Rompere le cose è un'abilità

Ho lavorato in troppi posti che hanno abbracciato l'argomento "se non è rotto" al punto che non riescono a innovare, e quando alla fine sono costretti a innovare reagiscono troppo cambiando tutto . Semplicemente perché mancano dell'esperienza nel rompere le cose .

Ci vogliono maturità, abilità ed esperienza per spezzare le cose.

I team di sviluppo che giocano sempre al sicuro sono i più facili da superare per un concorrente. Solo i team che hanno fallito, fatto errori e cose rotte sono in grado di fare veramente oneste valutazioni del rischio.

Mantenere lo status quo

Sebbene sia vero, l'attuale sistema soddisfa i requisiti aziendali attuali. Ciò non è vero per le future modifiche impreviste a tali requisiti. Come dice il vecchio proverbio "la fortuna preferisce i preparati".

Questa domanda non ha nulla a che fare con SQL o le prestazioni. Si tratta di porre la domanda "c'è un modo migliore?" e non aver paura di provare un'alternativa.

Il tuo capo soffre di un caso di Keeping The Status Quo .

I Maya

Niente funziona davvero alla perfezione.

I Maya continuavano a coltivare il cibo sul fianco delle montagne. Fino a quando tutti i nutrienti non sono stati lavati via e non hanno avuto modo di nutrire la loro gente. Continuavano a fare le cose allo stesso modo fino a quando non era troppo tardi.

Supponendo che avrai tempo per risolvere un problema quando il problema si presenta è un errore.

Cosa fare?

Il tuo capo soffre di un caso di condizionamento. Le persone che accettano lo status quo lo fanno spesso, perché non hanno la capacità di prendere decisioni difficili. Di fronte a una sfida, tenderanno a scegliere l'opzione più vicina a ciò che hanno familiarità.

La paura per lui è una grande motivazione. La paura dell'ignoto o delle condizioni mutevoli scuote la sua prospettiva di quello che è lo status quo. Tenderà a cercare di riportare le condizioni alla normalità il più rapidamente possibile.

Devi presentare idee in modo non conflittuale. Cerca di trovare un terreno comune tra ciò che vorresti fare con quello che è già lo status quo. Presentare argomenti che riducono la sua paura del cambiamento e offrire rassicurazioni sul fatto che si desidera completare un'attività che non causerà cambiamenti significativi.

Take Baby Steps

Sarebbe meglio offrire cambiamenti che spostino il progetto nella direzione desiderata, ma attraverso piccoli progetti incrementali. Piuttosto, colpisci il tuo capo con la grande domanda sul supporto di SSIS. Offri di creare un livello di separazione nel codice che ti consenta di inserire metodi "alternativi" per l'elaborazione di tabelle con allegati di grandi dimensioni. È quindi possibile progredire per raccomandare SSIS con tutti i prerequisiti già aggiunti al progetto. Ciò riduce il rischio che il tuo capo prevede accettando la modifica.

Richiede tempo

La mia esperienza è stata che gli acquirenti di rischi mantengono in movimento un progetto e che i detentori dello status quo sono come un muro di mattoni. La persistenza è la tua unica opzione per abbattere le loro barriere. Aspettatevi di continuare ad ascoltare No alle vostre richieste.

Quando arriva il momento di innovare. Il tuo capo si rivolgerà a te rapidamente, perché mostri coraggio senza far fronte al cambiamento. Qualcosa che una persona in status quo cercherà e sarai ricompensato per i tuoi sforzi. Anche se nessuna delle tue precedenti richieste è stata accettata. Diventerai rapidamente una risorsa insostituibile in un'azienda che deve affrontare un cambiamento che abbraccia il non-cambiamento.

Sento che se riscrivessimo alcune delle conversioni come pacchetti SSIS, questo potrebbe accelerare molto le cose. Tuttavia, il più grande muro di pietra in cui continuo a correre è quando il mio capo, in modalità Non inventato qui, fa un passo indietro e dice "Cosa succede se Microsoft elimina il supporto per SSIS? Avremo tutto questo codice obsoleto e saremo fregati".

Secondo me, lo scetticismo sull'SSIS è valido.

• Gli sviluppatori esperti odiano le scatole nere e c'è molta magia che accade all'interno di un pacchetto SSIS.
• Il supporto del controllo del codice sorgente per i pacchetti SSIS è gravemente carente. Diffondere e unire i file dtsx SSIS può essere un incubo se i pacchetti dtsx non sono sufficientemente modulari.
  • Al contrario, le applicazioni della console C # sono molto trasparenti. Puoi sempre seguire il codice per capire cosa non va.

Inoltre, considera che il tuo capo è agganciato se qualcosa va storto.

• Pertanto, ha il diritto di avere l'opinione prevalente / unica sulla questione.

Non ho il tempo di scrivere la conversione alla vecchia maniera, autodidatta a me stesso SSIS e anche di scriverla nel nuovo modo di dimostrare / testare i benefici (Nessuno di noi ha usato SSIS quindi ci sarebbe un periodo in cui vorremmo imparare a usarlo).

Cosa dovrei fare in questa situazione? Smetti di spingere la nuova tecnologia? Aspetta che lasci il dipartimento (io sono la seconda persona più anziana nel dipartimento dopo di lui, ma potrebbero passare anni prima che esca / si ritiri)? Trova un nuovo modo per convincerlo a smettere di aver paura degli strumenti di terze parti?

Ti consiglio di imparare SSIS abbastanza bene da poterne dimostrare i vantaggi.

E se, dopo il tuo studio personale, scopri che SSIS offre vantaggi significativi rispetto all'approccio più "tradizionale" e non riesci ancora a convincere il tuo capo a cambiare rotta, allora ti consiglio di trovare un lavoro diverso in cui puoi usa SSIS.

La risposta che provi quasi sempre dalla maggior parte dei tipi di manager è qualcosa del tipo:

"Non ne vale la pena, funziona ora e costerà tempo per cambiare".

E in generale, questo è valido. Tuttavia, questo non è sempre un argomento valido, perché il problema principale che circonda la sindrome di "Non inventato qui" non è se le cose funzionano o non funzionano, ma quella tecnologia viene inutilmente riscritta , sprecando ore in azienda e togliendo valore sostanziale dal prodotto consegnato.

Prima di decidere cosa fare, devi determinare se In realtà non si sta svolgendo qui. La tecnologia interna potrebbe essere stata scritta per un motivo .

Segni che la Tech viene riscritta per un motivo:

• Anche la tecnologia che stai vendendo è il prodotto . Se sei un fornitore di database, utilizzando il codice MySQL, non importa quanto tempo risparmi, è un'idea pericolosa per molte ragioni.
• La tecnologia interna è ben mantenuta e risolve efficacemente le carenze della soluzione standard, pur fornendo funzionalità di base comparabili.
• La tecnologia migliora la produttività dell'intero team di sviluppo e i nuovi sviluppatori vengono venduti facilmente sul perché è in uso.
• Vi sono altri esempi in cui la società ha adottato con successo altre tecnologie esterne .
• La tua attività sarebbe immediatamente e seriamente influenzata se la soluzione OTS fosse interrotta o rotta.
• L'azienda è così grande che ha le risorse per scrivere strumenti di alta qualità a basso costo (ad esempio, Google potrebbe essere in grado di scrivere un database che costa meno di una licenza MS SQL da $ 1000 / postazione)

In altre parole, il team comprende gli svantaggi della risoluzione di problemi già risolti, ma ha fatto giudiziosamente eccezioni laddove aveva senso dal punto di vista aziendale.

Segni di "Non inventato qui":

• Sembra che tutto sia interno e ci sono scuse per tutto: "uh, era troppo lento", "uh, è Microsoft, odiamo Microsoft", "uh, sembra davvero difficile da usare", ecc.
• Per i casi in cui viene utilizzata la tecnologia esterna, si sente "sì, beh, puzza e alla fine pensiamo di scrivere il nostro ".
• I proprietari di quei componenti non hanno altri lavori su cui sono in grado di lavorare.
• Vedi la maggior parte dei nuovi sviluppatori entrare con un set di competenze ampiamente accettato, ma ci vuole molto tempo per accelerare verso gli strumenti interni
• Dopo un'attenta analisi, diventa evidente che il passaggio dalla soluzione OTS a una soluzione OTS personalizzata o di altro tipo nel "che cosa succede se viene interrotto!" lo scenario avrebbe un impatto aziendale minimo . Ad esempio, se String.Join()fossero stati rimossi da .NET Framework, la reimplementazione in un StringJoin()metodo personalizzato sarebbe banale.

In altre parole, NIH è il modello che non riesce a rimanere oggettivo e realistico nei casi in cui viene utilizzata la tecnologia esterna al posto del proprio codice.

Quando la tecnologia viene riscritta per una ragione, i tuoi superiori dovrebbero essere elogiati e apprezzati dai tuoi superiori. Dovrebbe essere stata una decisione attenta quando la tecnologia è stata implementata e rivedere occasionalmente la decisione è positivo per l'azienda. Le cose cambiano nel tempo e potresti avere un punto valido. Se puoi fornire numeri sul tempo sprecato in passato, i costi previsti per il passaggio e altre informazioni, potresti (in teoria) fare un caso per passare.

Comprendi che, data la tua esperienza, potrebbero non essere d'accordo con i tuoi numeri, ma a prescindere, dovrebbero almeno ascoltarti. Potrebbe volerci del tempo per guadagnare rispetto.

Se la conversazione non può nemmeno essere sollevata, anche se sei educato, potrebbe essere semplicemente "Non inventato qui". Nel qual caso, è molto probabile che non sia possibile risolvere facilmente un problema politico o di personalità. Lavorare in un ambiente fortemente impantanato dalla costante reinvenzione è tossico per gli sviluppatori e il business. Correre.

(Nota a margine: nella maggior parte delle aziende, c'è sempre un elemento di NIH, ma è a un livello tollerabile e fintanto che rivedono regolarmente il loro codice e le loro pratiche. A lungo termine ne siamo tutti colpevoli in una certa misura, ma non diventa mai un problema.)

Bene, è tutto sull'analisi costi / benefici.

Cosa ottieni riscrivendolo in SSIS? Velocità? Importa? Se è un processo che viene eseguito in una GUI e fa perdere tempo a tutti, allora sì, probabilmente è una buona idea accelerarlo, perché i soldi spesi per cambiarlo verranno recuperati da clienti più soddisfatti o impiegati interni che fanno il loro lavoro invece di aspettando il software. Ma se è un lotto notturno che inizia alle 12:00 e termina all'01.00 anziché alle 6.00 ... non ha molto senso. Sì, è 6 volte più veloce, ma nessuno sentirà la differenza.

E il tuo capo ha un buon punto. Microsoft tende ad abbandonare alcune delle sue tecnologie. VB6, Linq-to-SQL, ASP classic, COM + ... Questo è un rischio con qualsiasi software non open source (e software open source che sarebbe troppo grande per essere gestito dall'organizzazione in caso di mancanza di aggiornamento). Se è fondamentale per la tua applicazione, dovresti avere uno stretto controllo su di essa.

Il software si basa sull'aggiunta di valore per il cliente e il miglioramento tecnico che non offre molti vantaggi mentre si introduce il rischio non svolge davvero quel ruolo.

Sviluppa un POC (Proof of Concept) e poi dimostralo al tuo superiore. Il POC dovrebbe aiutarti a determinare qualsiasi reale beneficio con la tecnologia che stai proponendo. Quindi tu e il tuo superiore potete parlare della tecnologia e sviluppare pro e contro per implementarla.

Probabilmente dovrai dedicare del tempo extra al di fuori del normale orario di lavoro per sviluppare il POC.

Come nota a margine dal punto di vista SSIS, l'ho usato e ho sviluppato pacchetti SSIS. In realtà abbiamo sostituito un processo di caricamento proprietario usando i pacchetti SSIS. Lo abbiamo fatto solo perché i clienti reali si sono lamentati dei tempi di caricamento. I tempi di caricamento sono diminuiti in modo significativo con SSIS e tutti sono diventati più felici.

SSIS è fondamentalmente un flusso di lavoro drag and drop con pochissima programmazione coinvolta. Ci vuole del tempo per imparare come funziona la scatola nera, quindi dovrai prenderla in considerazione se il tuo team inizia a usarla.

Buone risposte. Se non è rotto, non aggiustarlo. Vorrei solo aggiungere

• Mentre le preoccupazioni relative alle prestazioni potrebbero effettivamente essere vere, quella parola "potrebbe" è una bandiera rossa. Farei prima la diagnosi delle prestazioni, quindi avrei la prova di quale fosse il problema delle prestazioni, prima di impegnare qualsiasi risorsa per risolverlo.

• Quando si considera l'ultima "soluzione" di Microsoft, si dovrebbe considerare che un sacco di persone sono state bruciate da ciò che gli Stati Uniti una volta erano solenni, ma successivamente deprecate e quindi non supportate. Se vuoi che il software funzioni per 10 o 20 anni senza ricodificazioni importanti, dovresti essere molto cauto. La nostra azienda è stata gravemente ferita in quel modo.

Il fatturato sarà una considerazione per il tuo capo. SSIS sta entrando nell'arena DBA rispetto a un programmatore con quell'insieme di abilità. Se la tua applicazione non utilizza SSIS oltre la conversione iniziale, non sono sicuro che abbia senso impararla e velocizzare i nuovi programmatori C # perché, come il tuo team, molti non ne hanno esperienza.

Potresti far notare al tuo capo che SSIS è, in effetti, un livello tecnologico più vecchio di .NET Framework, se torni alle sue origini come "Data Transformation Framework" di SQL 7.0.

Il punto in cui il tuo capo potrebbe avere un punto è che SSIS è solo una parte delle versioni Standard ed Enterprise di Microsoft Sql Server; questo è un grosso cambiamento per i tuoi clienti a pony up, quando la tua applicazione, in uno scenario di piccole imprese, potrebbe benissimo andare bene con Sql Express (o MySQL, per quello che funziona con ADO.NET ma non può utilizzare l'integrazione SSIS).

Ora, lasciami essere perfettamente chiaro; IMO, NIH non è quasi mai una buona cosa per una casa di sviluppo software. Ti blocca fuori da molti strumenti e servizi molto potenti. È anche ipocrita sulla sua faccia; la tua azienda ha scritto Visual Studio? Che ne dici di .NET Framework? Server SQL? Finestre? No. Costruisci il tuo software sopra gli strumenti e le piattaforme che già possiedi (e così fanno i tuoi clienti). Pertanto, se vedi uno strumento che sta ottenendo un'accettazione generale e che potrebbe essere utile per svolgere il tuo core business, lo adotti e impari a convivere con il rischio che dovrai mantenere la tua implementazione per stare al passo con le ultime novità versioni di tali strumenti o addirittura sostituirli. Scommetto che il tuo capo prima ha sviluppato il software per funzionare su Windows 95/98 o successivi (in caso contrario lungoprima, come 3.0 / 3.1). Se è così, ha visto una mezza dozzina di versioni dei sistemi operativi delle workstation Windows andare e venire, e ha dovuto aggiornare il suo software per funzionare sulle piattaforme più recenti, e si trova ad affrontare un altro con XP ufficialmente EOLed. Mentre può lamentarsi, questo è semplicemente il costo di fare affari.

Tuttavia, un atteggiamento NIH non deriva necessariamente dal rifiuto di accettare una, o anche un numero, di tecnologie che possono essere considerate utili. Tali rifiuti potrebbero basarsi su analisi costi-benefici perfettamente valide. Lavoro per un'azienda di videosorveglianza e monitoraggio allarmi e prendiamo decisioni per supportare o meno varie nuove tecnologie o prodotti su base giornaliera. Di solito, la decisione di accettare una nuova tecnologia e il dolore di integrarla insieme al nostro ammasso esistente di software di visualizzazione e gestione degli allarmi supportati, si basa principalmente su ciò che vale per i nostri clienti. Di recente ho terminato un grande progetto di integrazione con un nuovo tipo di DVR, semplicemente perché uno dei nostri più grandi clienti esistenti ha affermato che stavano eseguendo l'upgrade a quel DVR da un altro prodotto DVR di grande nome ma tecnologicamente in ritardo, e lo farebbero con o senza il nostro aiuto. D'altra parte, rifiutiamo regolarmente i nuovi produttori, anche i nomi delle famiglie, semplicemente perché i nostri clienti non lo usano e non vediamo alcun valore nel cominciare a offrirlo, anche se ci perde alcuni potenziali clienti che ce l'hanno e non non voglio pagare per la nostra versione della stessa cosa.

Non ho il tempo di scrivere la conversione alla vecchia maniera, autodidatta a me stesso SSIS e anche di scriverla nel nuovo modo di dimostrare / testare i benefici (Nessuno di noi ha usato SSIS quindi ci sarebbe un periodo in cui vorremmo imparare a usarlo).

Questo è il problema, no? Stai chiedendo ad altre persone di rischiare la loro produttività sulla tua idea, e non sei disposto ad andare fuori di testa per mostrare loro che ne vale la pena. La leadership tecnica richiede il rischio della tua reputazione o del tempo libero per dimostrare che vale la pena avere le tue idee.

Cerca di vedere le cose dalla prospettiva del tuo capo. Sembra che la funzionalità che stai cercando di sostituire sia fondamentale per ciò che fa il tuo software (vedi il suo commento "fottuto"). Un buon manager sa che esternalizzare il core business a proprio rischio e pericolo. È giustamente preoccupato di scommettere sulla fattoria su un pezzo di tecnologia che potrebbe scomparire in futuro. Quando sono coinvolte le funzioni principali, Not Invented Here è in realtà una buona cosa.

Se la velocità è una caratteristica, dovrai trovare un altro modo per accelerare le cose. Altrimenti, se la velocità conta più per te che per i tuoi clienti, dico di lasciar perdere e dimenticartene.

Mentre c'è il merito di "non riparare ciò che non è rotto", non sono d'accordo con la risposta accettata.

La risposta accettata viene dalla prospettiva che il problema non è rotto. Dal punto di vista del management di medio livello, questo è vero. Se si dovesse fare un'analisi dei costi sul tempo impiegato dagli sviluppatori per creare e mantenere una soluzione ETL in C # rispetto all'acquisto di una soluzione pronta all'uso, mostrerebbe che la soluzione C # impiega 3-4 volte più a lungo per creare e mantenere e costare fino a 10 volte di più (ho cercato il riferimento sui numeri, ma non sono riuscito a trovarlo).

A meno che non sia la competenza principale dell'azienda, ci sono pochissime ragioni per scrivere e gestire le trasformazioni dei dati in C #. La soluzione fatta in casa sarà lenta, ci saranno errori (cioè dati corrotti), ci saranno casi limite, ci sarà un piccolo riutilizzo tra le classi ETL e sarà fragile. Onestamente, quale sviluppatore vuole trascorrere le sue giornate scrivendo e mantenendo ETL in C #? L'ho fatto. È un sacco di merda. È il più lontano possibile dal lavoro creativo.

Utilizza uno strumento come Informatica, un'azienda la cui attività è ETL. Stanno risolvendo questo problema da oltre 15 anni. Lo hanno risolto. I loro strumenti sono drag and drop, la riusabilità è integrata e le prestazioni. La maggior parte di chiunque (ovvero gli sviluppatori non ne hanno) può creare ETL con gli strumenti di Informatica. Non sto cercando di vendere Informatica, utilizzare qualsiasi strumento. Basta non reinventare la ruota.

A lungo termine, l'acquisto di uno strumento, come Informatica o l'utilizzo di SSIS, consentirà alla società di risparmiare milioni nel lungo periodo. E soprattutto non dovrai mantenere l'ETL o essere responsabile di esso quando si rompe.

Ho già provato SSIS a svolgere semplici compiti.

Può essere molto fastidioso, poiché anche i semplici compiti danno vita a diagrammi di complessità di livello medio-basso (no, non c'è altro modo di "codificarlo" se non i diagrammi). E i problemi di controllo del codice sorgente indicati dalla risposta di Jim non lo sapevo.

Problema laterale: quindi, per accelerare, suggerisco di ridurre le dimensioni delle transazioni per le immagini in blocco. Diciamo, ogni 800 invece di 5000 rocords. Può ridurre le dimensioni dell'I / O necessarie per supportare quella transazione.