Differenza tra Dichiarazione e PreparedStatement

L'istruzione preparata è una versione leggermente più potente di un'istruzione e dovrebbe essere sempre altrettanto rapida e facile da gestire come un'istruzione.
L'istruzione preparata può essere parametrizzata

La maggior parte dei database relazionali gestisce una query JDBC / SQL in quattro passaggi:

1. Analizzare la query SQL in entrata
2. Compilare la query SQL
3. Pianificare / ottimizzare il percorso di acquisizione dei dati
4. Eseguire la query ottimizzata / acquisire e restituire i dati

Un'istruzione procederà sempre attraverso i quattro passaggi precedenti per ogni query SQL inviata al database. Un'istruzione preparata pre-esegue i passaggi (1) - (3) nel processo di esecuzione sopra. Pertanto, quando si crea un'istruzione preparata, viene eseguita immediatamente una pre-ottimizzazione. L'effetto è ridurre il carico sul motore di database al momento dell'esecuzione.

Ora la mia domanda è: "C'è qualche altro vantaggio nell'usare la dichiarazione preparata?"

Vantaggi di un PreparedStatement:

• La precompilazione e la memorizzazione nella cache sul lato DB dell'istruzione SQL consentono un'esecuzione complessivamente più rapida e la possibilità di riutilizzare la stessa istruzione SQL in batch .

• Prevenzione automatica degli attacchi di iniezione SQL mediante escape incorporato di virgolette e altri caratteri speciali. Si noti che ciò richiede l'utilizzo di uno dei metodi per impostare i valoriPreparedStatement setXxx()

  preparedStatement = connection.prepareStatement("INSERT INTO Person (name, email, birthdate, photo) VALUES (?, ?, ?, ?)");
  preparedStatement.setString(1, person.getName());
  preparedStatement.setString(2, person.getEmail());
  preparedStatement.setTimestamp(3, new Timestamp(person.getBirthdate().getTime()));
  preparedStatement.setBinaryStream(4, person.getPhoto());
  preparedStatement.executeUpdate();

  e quindi non incorporare i valori nella stringa SQL concatenando la stringa.

  preparedStatement = connection.prepareStatement("INSERT INTO Person (name, email) VALUES ('" + person.getName() + "', '" + person.getEmail() + "'");
  preparedStatement.executeUpdate();

• Facilita impostazione di oggetti fuori standard Java in una stringa SQL, ad esempio Date, Time, Timestamp, BigDecimal, InputStream( Blob) e Reader( Clob). Sulla maggior parte di quei tipi non puoi "semplicemente" fare una cosa toString()come faresti in una semplice Statement. Potresti persino rifattorizzare tutto sull'uso PreparedStatement#setObject()all'interno di un ciclo, come dimostrato nel metodo di utilità seguente:

  public static void setValues(PreparedStatement preparedStatement, Object... values) throws SQLException {
      for (int i = 0; i < values.length; i++) {
          preparedStatement.setObject(i + 1, values[i]);
      }
  }

  Quale può essere usato come di seguito:

  preparedStatement = connection.prepareStatement("INSERT INTO Person (name, email, birthdate, photo) VALUES (?, ?, ?, ?)");
  setValues(preparedStatement, person.getName(), person.getEmail(), new Timestamp(person.getBirthdate().getTime()), person.getPhoto());
  preparedStatement.executeUpdate();

1. Sono precompilati (una volta), quindi più veloci per l'esecuzione ripetuta di SQL dinamico (in cui i parametri cambiano)

2. La memorizzazione nella cache delle istruzioni del database migliora le prestazioni di esecuzione del DB

   I database memorizzano le cache dei piani di esecuzione per le istruzioni eseguite in precedenza. Ciò consente al motore di database di riutilizzare i piani per le istruzioni eseguite in precedenza. Poiché PreparedStatement utilizza parametri, ogni volta che viene eseguito appare come lo stesso SQL, il database può riutilizzare il piano di accesso precedente, riducendo l'elaborazione. Le istruzioni "incorporano" i parametri nella stringa SQL e quindi non appaiono come lo stesso SQL nel DB, impedendo l'utilizzo della cache.

3. Il protocollo di comunicazione binaria significa meno larghezza di banda e chiamate di comunicazione più veloci al server DB

   Le istruzioni preparate vengono normalmente eseguite tramite un protocollo binario non SQL. Ciò significa che ci sono meno dati nei pacchetti, quindi le comunicazioni con il server sono più veloci. Come regola generale, le operazioni di rete sono un ordine di grandezza più lento delle operazioni del disco che sono un ordine di grandezza più lento delle operazioni della CPU in memoria. Pertanto, qualsiasi riduzione della quantità di dati inviati sulla rete avrà un effetto positivo sulle prestazioni complessive.

4. Proteggono dall'iniezione SQL, eseguendo l'escape del testo per tutti i valori dei parametri forniti.

5. Forniscono una maggiore separazione tra il codice della query e i valori dei parametri (rispetto alle stringhe SQL concatenate), aumentando la leggibilità e aiutando i manutentori del codice a comprendere rapidamente input e output della query.

6. In java, è possibile chiamare getMetadata () e getParameterMetadata () per riflettere rispettivamente sui campi del set di risultati e sui campi dei parametri

7. In java, accetta in modo intelligente oggetti java come tipi di parametri tramite setObject, setBoolean, setByte, setDate, setDouble, setDouble, setFloat, setInt, setLong, setShort, setTime, setTimestamp - converte in formato di tipo JDBC comprensibile per DB (non solo per String () formato).

8. In Java, accetta SQL ARRAY, come tipo di parametro tramite il metodo setArray

9. In java, accetta CLOB, BLOB, OutputStreams e Readers come parametri "feed" tramite setClob / setNClob, setBlob, setBinaryStream, setCharacterStream / setAsciiStream / setNCharacterStream, rispettivamente

10. In java, consente di impostare valori specifici per DB per DATALINK SQL, SQL ROWID, SQL XML e NULL tramite setURL, setRowId, setSQLXML e setNull metodi

11. In java, eredita tutti i metodi da Statement. Eredita il metodo addBatch e consente inoltre di aggiungere una serie di valori di parametro per abbinare la serie di comandi SQL in batch tramite il metodo addBatch.

12. In Java, un tipo speciale di PreparedStatement (la sottoclasse CallableStatement) consente di eseguire le procedure memorizzate, supportando prestazioni elevate, incapsulamento, programmazione procedurale e SQL, amministrazione / manutenzione DB / modifica della logica e utilizzo di logiche e caratteristiche DB proprietarie

PreparedStatementè un'ottima difesa (ma non infallibile) nel prevenire attacchi di iniezione SQL . I valori dei parametri vincolanti sono un buon modo per proteggersi dai "piccoli tavoli Bobby" che fanno una visita indesiderata.

Alcuni dei vantaggi di PreparedStatement over Statement sono:

1. PreparedStatement ci aiuta a prevenire attacchi di iniezione SQL perché sfugge automaticamente ai caratteri speciali.
2. PreparedStatement ci consente di eseguire query dinamiche con input di parametri.
3. PreparedStatement fornisce diversi tipi di metodi setter per impostare i parametri di input per la query.
4. PreparedStatement è più veloce di Statement. Diventa più visibile quando riutilizziamo PreparedStatement o utilizziamo i suoi metodi di elaborazione batch per eseguire più query.
5. PreparedStatement ci aiuta a scrivere codice orientato agli oggetti con metodi setter mentre con Statement dobbiamo usare la concatenazione di stringhe per creare la query. Se ci sono più parametri da impostare, scrivere Query usando la concatenazione di stringhe sembra molto brutto e soggetto a errori.

Maggiori informazioni sul problema di iniezione SQL su http://www.journaldev.com/2489/jdbc-statement-vs-preparedstatement-sql-injection-example

non c'è molto da aggiungere,

1 - se si desidera eseguire una query in un ciclo (più di 1 volta), l'istruzione preparata può essere più veloce, a causa dell'ottimizzazione menzionata.

2 - la query con parametri è un buon modo per evitare l'iniezione SQL. Le query con parametri sono disponibili solo in PreparedStatement.

L'istruzione è statica e la dichiarazione preparata è dinamica.

L'istruzione è adatta per DDL e istruzioni preparate per DML.

L'istruzione è più lenta mentre l'istruzione preparata è più veloce.

più differenze (archiviate)

Non è possibile eseguire CLOB in una dichiarazione.

E: (OraclePreparedStatement) ps

Come citato da mattjames

L'uso di un'istruzione in JDBC deve essere localizzato al 100% per essere utilizzato per DDL (ALTER, CREATE, GRANT, ecc.) In quanto questi sono gli unici tipi di istruzione che non possono accettare VARIABILI BIND. PreparedStatements o CallableStatements devono essere utilizzati per OGNI ALTRO tipo di istruzione (DML, Query). Poiché questi sono i tipi di istruzione che accettano variabili di bind.

Questo è un fatto, una regola, una legge - usa dichiarazioni preparate OVUNQUE. Usa DICHIARAZIONI quasi da nessuna parte.

l'iniezione sql viene ignorata dall'istruzione preparata, quindi la sicurezza aumenta nell'istruzione preparata

• È più facile da leggere
• Puoi facilmente rendere costante la stringa di query

L'istruzione verrà utilizzata per l'esecuzione di istruzioni SQL statiche e non può accettare parametri di input.

PreparedStatement verrà utilizzato per eseguire più volte istruzioni SQL in modo dinamico. Accetterà i parametri di input.

Un'altra caratteristica della query preparata o parametrizzata: riferimento tratto da questo articolo.

Questa affermazione è una delle caratteristiche del sistema di database in cui la stessa istruzione SQL viene eseguita ripetutamente con alta efficienza. Le istruzioni preparate sono un tipo di modello e utilizzate dall'applicazione con parametri diversi.

Il modello di istruzione viene preparato e inviato al sistema di database e il sistema di database esegue l'analisi, la compilazione e l'ottimizzazione su questo modello e lo memorizza senza eseguirlo.

Alcuni parametri come, in cui la clausola non viene passata durante la successiva creazione del modello, inviano questi parametri al sistema del database e il sistema del database utilizza il modello dell'istruzione SQL ed esegue secondo la richiesta.

Le istruzioni preparate sono molto utili contro SQL Injection poiché l'applicazione può preparare parametri utilizzando tecniche e protocolli diversi.

Quando il numero di dati aumenta e gli indici cambiano frequentemente in quel momento, le istruzioni preparate potrebbero non riuscire perché in questa situazione è necessario un nuovo piano di query.

Statement l'interfaccia esegue istruzioni SQL statiche senza parametri

PreparedStatement interface (extending Statement) esegue un'istruzione SQL precompilata con / senza parametri

1. Efficiente per esecuzioni ripetute

2. È precompilato, quindi è più veloce

Non avere confusione: ricorda semplicemente

1. L'istruzione viene utilizzata per query statiche come DDL, ad esempio create, drop, alter e preparStatement viene utilizzato per query dinamiche, ad esempio query DML.
2. In Statement, la query non è precompilata mentre nella preparazioneizeStatement la query è precompilata, a causa di ciò preparStatement è efficiente in termini di tempo.
3. preparStatement prende argomento al momento della creazione mentre Statement non accetta argomenti. Ad esempio, se si desidera creare una tabella e inserire un elemento, allora :: Creare una tabella (statica) utilizzando Istruzione e Inserisci elemento (dinamico) utilizzando preparStatement.

Ho seguito tutte le risposte a questa domanda per cambiare un codice legacy funzionante usando - Statement(ma avendo iniezioni SQL) in una soluzione usando PreparedStatementun codice molto più lento a causa della scarsa comprensione della semantica attorno a Statement.addBatch(String sql)& PreparedStatement.addBatch().

Quindi sto elencando il mio scenario qui in modo che gli altri non commettano lo stesso errore.

Il mio scenario era

Statement statement = connection.createStatement();

for (Object object : objectList) {
    //Create a query which would be different for each object 
    // Add this query to statement for batch using - statement.addBatch(query);
}
statement.executeBatch();

Quindi nel codice sopra ho avuto migliaia di query diverse, tutte aggiunte alla stessa istruzione e questo codice ha funzionato più velocemente perché le istruzioni che non venivano memorizzate nella cache erano buone e questo codice veniva eseguito raramente nell'app.

Ora per correggere le iniezioni SQL, ho cambiato questo codice in,

List<PreparedStatement> pStatements = new ArrayList<>();    
for (Object object : objectList) {
    //Create a query which would be different for each object 
    PreparedStatement pStatement =connection.prepareStatement(query);
    // This query can't be added to batch because its a different query so I used list. 
    //Set parameter to pStatement using object 
    pStatements.add(pStatement);
}// Object loop
// In place of statement.executeBatch(); , I had to loop around the list & execute each update separately          
for (PreparedStatement ps : pStatements) {
    ps.executeUpdate();
}

Quindi, vedete, ho iniziato a creare migliaia di PreparedStatementoggetti e alla fine non sono stato in grado di utilizzare il batch perché il mio scenario lo richiedeva: ci sono migliaia di query UPDATE o INSERT e tutte queste query sono diverse.

La correzione dell'iniezione SQL era obbligatoria senza alcun costo per il degrado delle prestazioni e non credo che sia possibile PreparedStatementin questo scenario.

Inoltre, quando si utilizza la funzione di batch integrata, è necessario preoccuparsi di chiudere una sola istruzione ma con questo approccio Elenco, è necessario chiudere la dichiarazione prima di riutilizzarla, Riutilizzo di una dichiarazione preparata