Il confronto di un compilatore OO con un compilatore / ottimizzatore SQL è valido?

Dici che questo è il tuo lavoro nuovo ? Quasi ogni parola che dicono è assolutamente sbagliata.

• Esecuzione su script SQL a mille righe - Questo non è quasi mai "buono"
• Il refactoring è sbagliato - È come ottenere qualche graffio sul lavoro di verniciatura della tua auto e insistere sul fatto che devi acquistare una nuova auto
• Il grande muro di codice è migliore - Quasi mai. La cosa più importante del refactoring di solito è che ti aiuta a rimuovere entrambe le operazioni di e ridondanti (ad esempio, renderlo più veloce)
• I compilatori OO non sono inefficienti. Certo, in alcuni casi puoi scrivere codice più veloce in C, ma l'impatto sulle prestazioni dell'1% non ha importanza se non puoi vedere che il tuo Algorithm è O (n ^ 2) invece di O (n)
• SQL non è una lingua "veloce". Fare cose in SQL diverse da quelle per cui è progettato è una cattiva idea.

Fondamentalmente, si scrive C su C # / Java quando è necessario. I casi migliori si hanno quando si hanno a che fare con dettagli di basso livello (driver, integrati), o quando si sa veramente che è necessario avere un po 'di velocità da un pezzo di codice. Confrontare un compilatore OO con un compilatore SQL non ha alcun senso. Certo, puoi scrivere algoritmi complessi (non orientati ai dati) in SQL, ma sarà lento, avrà una qualità del codice orribile e generalmente farà schifo perché SQL NON è stato progettato per questo. È stato progettato per ottenere i tuoi dati da una serie di tabelle e trasferirli in una lingua più competente.

Perché SQL non è veloce:

• Per uno, non è in realtà un confronto equo. SQL da solo non è completato da Turing. Suppongo che tu stia parlando di T-SQL o simili
• Applica strutture pesanti per tipi di dati semplici. Che cosa fai se il tuo algoritmo ha bisogno dell'equivalente di un hash-table o di un dizionario? Le tabelle temporanee sono piuttosto pesanti, in particolare per le versioni precedenti dei server SQL
• SQL è progettato in modo tale che non è possibile eseguire determinate ottimizzazioni perché è progettato per il recupero e l'aggiornamento dei dati

Buon confronto, SQL Server contro C # per la semplice operazione di ottenere la lunghezza di una stringa: confronto . Inoltre, questo non è nemmeno un vero confronto. Questo utilizza il bridge SQL-CLR, che ovviamente ha un sovraccarico, ma ottieni il punto. L'utilizzo di SQL puro ha una durata 30 volte più lenta rispetto al richiamo di una funzione C # da SQL per questa operazione

Non confrontare nulla con il modo migliore per scrivere SQL con ciò che hai imparato nella programmazione orientata agli oggetti. È una bestia completamente diversa.

Nel lavoro di database ci occupiamo principalmente del codice che realizza tre cose:

• Conservazione dell'integrità dei dati
• Prestazioni del database
• Sicurezza dei dati

Tutto il codice dovrebbe essere valutato sulla base di questi tre fattori sopra ogni altra cosa.

Le persone del database sono intrinsecamente prudenti riguardo al refactoring perché possono influenzare drasticamente l'integrità dei dati o causare enormi rallentamenti delle prestazioni sulle macchine di produzione se eseguite in modo errato. Ci sono modi per refactoring con successo, ma un sistema per esso ha bisogno di essere impostato e devi avere buy in dal dbas. Posso suggerire un libro di munirvi di munizioni per aiutare a realizzare un sistema di refactoring:

link

Ci sono un paio di cose che succedono qui, quindi è tornato al momento di base. Come regola generale, quando stai implementando vuoi fare cose:

1. Completa
2. Corretto
3. Ottimizzato

L'ottimizzazione prima di completare o correggere le cose avrà un impatto negativo sulla pianificazione e, probabilmente, sulla qualità. Se ti viene detto di farlo senza ragioni e esempi tecnici concreti, hai a che fare con la superstizione e non con la scienza. Per quanto riguarda il problema del refactoring, il refactoring è uno strumento di ottimizzazione - si rifatta l'ottimizzazione. Obiettare ciò significa solo che gli sviluppatori hanno una scarsa comprensione di cosa sia il refactoring.

I passaggi di ottimizzazione sono:

1. Profilo
2. Analisi
3. Ottimizza
4. Ripeti

Chiunque gestisca un database di grandi dimensioni che non stia operando da quelle regole non sta mantenendo un grande database funzionante, o ha ereditato un buon sistema che non ha ancora incasinato.

Sembra che tu sia caduto in una cultura che è un po 'superstiziosa sul perché hanno successo e su come funziona il sistema. Forse hanno ereditato un sacco di codice e perso l'architetto? O c'è un "genio" che mantiene tutto funzionante per forza di volontà? Ad ogni modo, non puoi combattere la religione su larga scala. Scegli le piccole cose e fai quello che sai è meglio. Essere rigorosi, fornire dati e avere successo. Ciò ti farà vincere nel tempo. Almeno, finché funziona, non si scherza con il tuo mojo. ;)

Non penso che vedrai più ampi compromessi con: riutilizzo, leggibilità e scalabilità rispetto a un RDBMS. I database di refactoring non sono gli stessi di altre basi di codice.

Riutilizzo - raramente lavorerai con un linguaggio di programmazione in cui trasformi un blocco di codice in un metodo e fai un notevole calo di prestazioni anche in un lungo ciclo di esecuzione. Questo è l'opposto in sql, ogni rdbms ha le sue peculiarità in cui riutilizzare le funzioni (inserire un'istruzione select e avere te stesso un ciclo) e le visualizzazioni possono drasticamente rallentare le prestazioni e devono essere usate con cautela.

Leggibilità: supponiamo che sql sia costantemente formato o almeno abbastanza vicino. Vedere i lunghi processi di memorizzazione che hanno creato tutti i tipi di tabelle temporanee e gli aggiornamenti e gli inserimenti dei dati utilizzati per infastidirmi perché non ero abituato. Se vuoi fare un nodo nello sfintere di un DBA, chiedi di cambiare il nome di una tabella in produzione perché il suo scopo non è chiaro.

Scalabilità: non vedrai molti punti in cui Riutilizzo e leggibilità (esclusi i motivi estetici) ostacoleranno la scalabilità / le prestazioni come in SQL. Oltre a un codice migliorato, è necessario indicizzare, gestire i file e possibilmente clustering, ma il codice di correzione che funziona male è un buon punto di partenza.

Questo non significa che non si possa ottenere alcun beneficio dal refactoring del database. Se puoi imparare come farlo in un modo che migliori le prestazioni, non è così difficile vendere.