Don't just automatically use prepare() for all of your queries.
If you are only submitting one query, using PDO::query() with PDO::quote() is much faster (about 3x faster in my test results with MySQL). A prepared query is only faster if you are submitting thousands of identical queries at once (with different data).
If you Google for performance comparisons you will find that this is generally consistently the case, or you can write some code and do your own comparison for your particular configuration and query scenario. But generally PDO::query() will always be faster except when submitting a large number of identical queries. Prepared queries do have the advantage of escaping the data for you, so you have to be sure to use quote() when using query().
PDO::prepare
(PHP 5 >= 5.1.0, PECL pdo >= 0.1.0)
PDO::prepare — Çalıştırılmak üzere bir deyimi hazırlar ve bir deyim nesnesi olarak döndürür
Açıklama
PDOStatement::execute() yöntemi ile çalıştırılmak üzere bir SQL deyimi hazırlar. SQL deyimi sıfır veya daha fazla sayıda birer isimle (:isim) veya birer soru imi (?) ile ifade edilen değiştirge içerebilir. Deyimin çalıştırılması sırasında bu değiştirgelere farklı değerler atanarak aynı deyim defalarca kullanılabilir. Aynı SQL deyiminde hem isimli hem de soru imli değiştirgeleri kullanamazsınız. İkisinden birini seçmek zorundasınız.
PDOStatement::execute() işlevinde aktaracağınız her değer için eşsiz bir değiştirge imleyici belirtmelisiniz. İsimli değiştirgeler eşsiz olmak zorundadır, aynı ismi birden fazla değiştirgede kullanamazsınız. Çok sayıda değeri, örneğin bir SQL deyiminin IN cümleciğinde tek bir isimli değiştirgeyle ilişkilendiremezsiniz.
Bir SQL deyiminin farklı değerlerle defalarca çalıştırılmak üzere PDO::prepare() ve PDOStatement::execute() yöntemlerine aktarılması, bu SQL deyimiyle ilgili sorgu planının ve temel verilerin müzakere edilmek üzere sürücü tarafından istemci ve/veya sunucu tarafında önbelleklemesiyle uygulamanızın başarımını yükseltecek en iyilemelerin yapılması mümkün olur ve değiştirgelerin elle öncelenmesi gereğini ortadan kaldırarak SQL zerk saldırılarını engellemeye yardımcı olur.
Değiştirgeli hazır deyimlerin değerlerle ilişkilendirilmesi işlemini desteklemeyen sürücüler için PDO bu işlemi taklit eder. Ayrıca sürücü isimli ve soru imli değiştirge aktarım tarzlarından yalnız birini destekliyorsa PDO diğer tarzı da taklit eder.
Değiştirgeler
-
deyim -
Hedef veritabanı sunucusu için geçerli bir SQL deyimi olmalıdır.
-
seçenekler -
Bu yöntemden döndürülen PDOStatement nesnesi için atanacak öznitelik değerlerini isim=>değer çiftleri halinde içeren bir dizi. Çoğunlukla kaydırılabilen bir gösterici isteği için PDO::CURSOR_SCROLL özniteliğine PDO::ATTR_CURSOR değerini atamakta kullanılır. Bazı sürücülerin deyimin hazırlanması aşamasında atanabilen sürücüye özgü öznitelikleri vardır.
Dönen Değerler
Veritabanı sunucusu deyimi başarıyla hazırlayabilmişse PDO::prepare() bir PDOStatement nesnesi döndürür; aksi takdirde bir PDOException istisnası oluşur.
Bilginize:
Taklit hazır deyimler için veritabanı sunucusuyla müzakere yapılmadığından PDO::prepare() deyim üzerinde bir sınama yapmaz.
Örnekler
Örnek 1 - İsimli değiştirgelerle bir SQL deyiminin hazırlanması
<?php
/* Değerleri bir dizi olarak aktaracağımız bir deyim hazırlayalım */
$sql = 'SELECT name, colour, calories
FROM fruit
WHERE calories < :calories AND colour = :colour';
$sth = $dbh->prepare($sql, array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY));
$sth->execute(array(':calories' => 150, ':colour' => 'red'));
$red = $sth->fetchAll();
$sth->execute(array('calories' => 175, 'colour' => 'yellow'));
$yellow = $sth->fetchAll();
?>
Örnek 2 - Soru imli değiştirgelerle bir SQL deyiminin hazırlanması
<?php
/* Değerleri bir dizi olarak aktaracağımız bir deyim hazırlayalım */
$sth = $dbh->prepare('SELECT name, colour, calories
FROM fruit
WHERE calories < ? AND colour = ?');
$sth->execute(array(150, 'red'));
$red = $sth->fetchAll();
$sth->execute(array(175, 'yellow'));
$yellow = $sth->fetchAll();
?>
Ayrıca Bakınız
- PDO::exec() - Belirtilen SQL deyimini çalıştırır ve etkilenen satır sayısını döndürür
- PDO::query() - Bir SQL deyimini çalıştırıp sonucu bir PDOStatement nesnesi olarak döndürür
- PDOStatement::execute() - Bir hazır deyimi çalıştırır
With PDO_MYSQL you need to remember about the PDO::ATTR_EMULATE_PREPARES option.
The default value is TRUE, like
$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,true);
This means that no prepared statement is created with $dbh->prepare() call. With exec() call PDO replaces the placeholders with values itself and sends MySQL a generic query string.
The first consequence is that the call $dbh->prepare('garbage');
reports no error. You will get an SQL error during the $dbh->exec() call.
The second one is the SQL injection risk in special cases, like using a placeholder for the table name.
The reason for emulation is a poor performance of MySQL with prepared statements. Emulation works significantly faster.
For those of you subclassing PDO while using PHP_STRICT...
While the above suggests the signature for this method is:
public function prepare ($statement, array $driver_options = array());
In fact you need to use:
public function prepare ($statement, $driver_options = array());
PDO::prepare will however barf an error if parameter 2 is not an array (including if it is null)
Using PDO to do database introspection...
<?php
// Get a list of tables
$tables = array();
$sql = "SHOW TABLES";
$stm = $this->prepare($sql);
$result = $stm->execute();
$columnname = 'Tables_in_'. $config['database'];
while( $row = $stm->fetchObject() ){
$tables[] = $row->$columnname;
}
print_r($tables);
?>
I just found that it is not possible to prepare "SHOW CREATE TABLE ?" nor "SHOW CREATE TABLE :tablename" however, doing it with string concatenation worked fine:
<?php
$schemas = array();
foreach($tables as $table)
{
$sql = 'SHOW CREATE TABLE '. $table;
$stm = $this->prepare($sql);
$result = $stm->execute();
$columnname = 'Create Table';
while( $row = $stm->fetchObject() ){
$schemas[$table] = $row->$columnname;
}
}
print_r($schemas);
?>
PDO::CURSOR_SCROLL is ok with MSS.
You must install SQL Server Driver for PHP 2.0 CTP2 : SQLSRV20.EXE
and the native client "Microsoft SQL Server 2008 R2 Native Client" : sqlncli.msi.
Note that PDO::CURSOR_SCROLL is **not** supported or emulated by the MySQL PDO driver, nor is a warning thrown.
See: http://bugs.php.net/bug.php?id=44475
Use prepared statements to ensure integrity of binary data during storage and retrieval. Escaping/quoting by f.e. sqlite_escape_string() or PDO::quote() is NOT suited for binary data - only for strings of text.
A simple test verifies perfect storage and retrieval with prepared statements:
<?php
$num_values = 10000;
$db = new pdo( 'sqlite::memory:' );
$db->exec( 'CREATE TABLE data (binary BLOB(512));' );
// generate plenty of troublesome, binary data
for( $i = 0; $i < $num_values; $i++ )
{
for( $val = null, $c = 0; $c < 512/16; $c++ )
$val .= md5( mt_rand(), true );
@$binary[] = $val;
}
// insert each value by prepared statement
for( $i = 0; $i < $num_values; $i++ )
$db->prepare( 'INSERT INTO data VALUES (?);' )->execute( array($binary[$i]) );
// fetch the entire row
$data = $db->query( 'SELECT binary FROM data;' )->fetchAll( PDO::FETCH_COLUMN );
// compare with original array, noting any mismatch
for( $i = 0; $i < $num_values; $i++ )
if( $data[$i] != $binary[$i] ) echo "[$i] mismatch\n";
$db = null;
?>
Maybe everyone else already knows this but...
If you have a routine that prepares/executes many insert or update statements for a sqlite db then you may want to make use of the pdo transactions.
On some old hardware my query set went from 12 seconds to 1/3-1/2 second.
-sean
beware
PDO will emulate prepared statements/bound parameters for drivers that do not natively support them, and can also rewrite named or question mark style parameter markers to something more appropriate, if the driver supports one style but not the other.
This includes mySQL it seems so
<?php
try{
$sth1 = $this->db1->prepare($t1, array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY));
}
catch(PDOException $e){
return $this->pack('dbError', $e->getMessage());
}
?>
does not and so will not throw the exception if your SQL is wrong.
You will need to check that $sth1 is not null.
You can also pass an array of values to PDOStatement::execute(). This is also secured against SQL injection. You don't necessarily have to use bindParam() or bindValue().
Note on the SQL injection properties of prepared statements.
Prepared statements only project you from SQL injection IF you use the bindParam or bindValue option.
For example if you have a table called users with two fields, username and email and someone updates their username you might run
UPDATE `users` SET `user`='$var'
where $var would be the user submitted text.
Now if you did
<?php
$a=new PDO("mysql:host=localhost;dbname=database;","root","");
$b=$a->prepare("UPDATE `users` SET user='$var'");
$b->execute();
?>
and the user had entered User', email='test for a test the injection would occur and the email would be updated to test as well as the user being updated to User.
Using bindParam as follows
<?php
$var="User', email='test";
$a=new PDO("mysql:host=localhost;dbname=database;","root","");
$b=$a->prepare("UPDATE `users` SET user=:var");
$b->bindParam(":var",$var);
$b->execute();
?>
The sql would be escaped and update the username to User', email='test'
Using cursors doesn't work with SQLite 3.5.9. I get an error message when it gets to the execute() method.
Some of you might be saying "duh!" but i was surprised to see TRIGGER support in SQLite, so i had to try. :)
I wanted to use Absolute referencing on a Scrollable cursor and i only wanted one column of data. So i used this instead of a cursor.
<?php
$dbo = new PDO('sqlite:tdb');
$sql = 'SELECT F1, F2 FROM tblA WHERE F1 <> "A";';
$res = $dbo->prepare($sql);
$res->execute();
$resColumn = $res->fetchAll(PDO::FETCH_COLUMN, 0);
for($r=0;$r<=3;$r++)
echo 'Row '. $r . ' returned: ' . $resColumn[$r] . "\n";
$dbo = null;
$res = null;
?>
Using prepared SELECT statements on a MySQL database prior to MySQL 5.1.17 can lead to SERIOUS performance degradation.
Quote from http://dev.mysql.com/doc/refman/5.1/en/query-cache.html :
>> The query cache is not used for server-side prepared statements before MySQL 5.1.17 <<
The MySQL query cache buffers complete query results and is used to satisfy repeated identical queries if the underlying tables do not change in the meantime - just what happens all the time in a typical web application. It speeds up queries by a several hundred to a several thousand percent.
Obviously, it doesn't make much sense to give up query caching for the relatively small performance benefit of prepared statements (i.e. the DBMS not having to parse and optimize the same query multiple times) - so using PDO->query() for SELECT statements is probably the better choice i you're connecting to MySQL < 5.1.17.
Please note that the statement regarding driver_options is misleading:
"This array holds one or more key=>value pairs to set attribute values for the PDOStatement object that this method returns. You would most commonly use this to set the PDO::ATTR_CURSOR value to PDO::CURSOR_SCROLL to request a scrollable cursor. Some drivers have driver specific options that may be set at prepare-time"
From this you might think that scrollable cursors work for all databases, but they don't! Check out this bug report:
http://bugs.php.net/bug.php?id=34625
If you need to create variable sql statements in a prepare statement...for example you may need to construct a sql query with zero, one, two, etc numbers of arguments...here is a way to do it without a lot of if/else statements needed to glue the sql together:
<?php
public function matchCriteria($field1=null,$field2=null,$field3=null) {
$db=DB::conn();
$sql=array();
$paramArray=array();
if(!empty($field1)) {
$sql[]='field1=?';
$paramArray[]=$field1;
}
if(!empty($field2)) {
$sql[]='field2=?';
$paramArray[]=$field2;
}
if(!empty($field3)) {
$sql[]='field3=?';
$paramArray[]=$field3;
}
$rs=$db->prepare('SELECT * FROM mytable'.(count($paramArray)>0 ? ' WHERE '.join(' AND ',$sql) : ''));
$result=$rs->execute($paramArray);
if($result) {
return $rs;
}
return false;
}
?>
Watch out: prepared statements on MySQL barf if you try to pass in substitution tables for sql keywords, table names, view names and field names.
For example, this will not work:
$stmt = $dbh->prepare("SELECT :sqlAggregate( :fieldName) from :viewName";
You will get a MySQL error 1064 and a very unhelpful error message.
In short, you need to do string substitutions into your queries if you want configurable table names, aggregate keywords etc etc.
Which doesn't help at all in the "protection from injection attacks" thing. A very annoying discovery.
Surely if you want to use prepared statements that way you should use the syntax in the second example:
eg.
instead of:
select id,name from demo_de where name LIKE :name OR name=:name
use:
select id,name from demo_de where name LIKE ? OR name=?
I believe you are supposed to either use distinct named parameters (name, name1) OR anonymous parameters (?s)
Attention using MySQL and prepared statements.
Using a placeholder multiple times inside a statement doesn't work. PDO just translates the first occurance und leaves the second one as is.
select id,name from demo_de where name LIKE :name OR name=:name
You have to use
select id,name from demo_de where name LIKE :name OR name=:name2
and bind name two times. I don't know if other databases (for example Oracle or MSSQL) support multiple occurances. If that's the fact, then the PDO behaviour for MySQL should be changed.
