2013-05-26 10 views
5

Ho questa stessa domanda per chiarire le cose. Ho letto alcuni documenti e commenti in giro ma ancora qualcosa non sono abbastanza chiari.PDO vs MYSQLI, Statemens preparati e Parametri di rilegatura

  • Capisco PDO offre più driver che sarebbe sicuramente un vantaggio se si dovesse mai cambiare il tipo di database.
  • Come detto in un altro post, DOP doesnt offrono vere istruzioni preparate ma mysqli fa quindi sarebbe più sicuro utilizzare MySQLi
  • benchmark sembra simile, (non l'ho provato io stesso, ma controllato in giro sul web per alcuni parametri di riferimento)
  • Essendo orientato agli oggetti non è un problema per me dal momento che mysqli sta recuperando. Ma sarebbe bello fare un benchmark mysqli procedurale rispetto a PDO visto che il procedimento dovrebbe essere leggermente più veloce.

Ma qui è la mia domanda, con la dichiarazione preparata, dobbiamo usare il collegamento dei parametri con i dati che usiamo nella nostra dichiarazione? buone pratiche o devono? Comprendo che le dichiarazioni preparate sono buone in termini di perfermance se si esegue la stessa query più volte ma è sufficiente per proteggere la query stessa? o i parametri vincolanti sono obbligatori? Cosa fanno esattamente i parametri di binding e come funziona per proteggere i dati da SQL injection? Sarebbe anche gradito se lei indicasse qualsiasi nostro fraintendimento riguardo alle affermazioni che ho fatto sopra.

grazie

+0

[Le istruzioni preparate devono essere utilizzate solo per l'escape?] (Http://stackoverflow.com/a/16365669/285587) –

+0

qual è il post che dichiara che PDO non supporta le istruzioni preparate in modo nativo? Deve essere cancellato o almeno downvoted –

+0

http://stackoverflow.com/questions/134099/are-pdo-prepared-statements-sufficient-to-prevent-sql-injection, Quote => "La cosa importante da realizzare qui è che PDO di default NON esegue affermazioni vere e preparate, ma le emula (per MySQL). ", Può essere frainteso ... – Leon

risposta

4

In breve,

  • Binding è un must, essendo la pietra angolare di protezione, non importa se supportata dal driver originale oppure no. È l'idea stessa di sostituzione che conta.
  • La differenza è trascurabile sia in sicurezza e le prestazioni, salvo i pochi casi limite
  • prestazioni è l'ultima cosa da considerare. Non c'è alcuna API che sia considerevolmente più lenta di altre. Non è una classe o una funzione che può causare qualsiasi problema di prestazioni ma manipolazione dei dati o algoritmo errato. Ottimizza le tue domande - c'è un modo per andare - non semplici funzioni per chiamarle.
  • Se si utilizza API raw non elaborata, PDO è l'unica scelta. Essendo avvolto in una classe di livello superiore, mysqli sembra più preferibile per mysql.
  • Sia mysqli che PDO mancano di binding per i letterali importanti che lo sviluppatore deve scrivere da soli, vedere safeMysql per l'esempio.
+0

Se usiamo correttamente le istruzioni preparate ei parametri di binding come dovrebbero, allora continuiamo a considerare l'utilizzo di safeMysql o la creazione della nostra classe? Capisco che sia utile per "conveniente perché rende il codice dell'applicazione breve e significativo, senza inutili ripetizioni, rendendolo Extra DRY" come menzionato sul loro sito web. – Leon

+0

Perché "Sia mysqli che PDO mancano di binding per i letterali importanti" - identificatori per esempio.Prova a associare un nome di campo in mysqli o PDO e vedi. Anche la dichiarazione IN può diventare un problema. L'idea stessa della classe safeMysql è quella di fornire un segnaposto per il * tutto * che può essere aggiunto alla query, non solo 1 o 2 tipi di dati come mysqli. –