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
PDO::prepare
(PHP 5 >= 5.1.0, PECL pdo >= 0.1.0)
PDO::prepare — Prépare une requête à l'exécution et retourne un objet
Description
Prépare une requête SQL à être exécutée par la méthode PDOStatement::execute(). La requête SQL peut contenir zéro ou plusieurs noms (:nom) ou marqueurs (?) pour lesquels les valeurs réelles seront substituées lorsque la requête sera exécutée. Vous ne pouvez pas utiliser les marqueurs nommés et les marqueurs interrogatifs dans une même requête SQL ; choisissez l'un ou l'autre.
Vous devez inclure un marquer avec un nom unique pour chaque valeur que vous souhaitez passer dans la requête lorsque vous appelez PDOStatement::execute(). Vous ne pouvez pas utiliser un marqueur avec deux noms pareils dans une requête préparée. Vous ne pouvez associer plusieurs valeurs à un seul marqueur de nom entrant, par exemple, la clause IN() d'une requête SQL.
Appeler PDO::prepare() et PDOStatement::execute() pour les requêtes qui doivent être exécutées plusieurs fois avec différentes valeurs de paramètres optimisent les performances de votre application en autorisant le pilote à négocier coté client et/ou serveur avec le cache des requêtes et les metainformations, et aident à prévenir les attaques par injection SQL en éliminant le besoin de protéger les paramètres manuellement.
PDO émule les requêtes préparées / les paramètres liés pour les pilotes qui ne le supportent pas nativement, et peut également réécrire les paramètres nommés ou les marqueurs en quelques choses de plus approprié, si le pilote supporte un style et pas l'autre.
Liste de paramètres
- statement
-
Doit être une requête SQL valide pour le serveur de base de données cible.
- driver_options
-
Ce tableau contient une ou plusieurs paires clé=>valeur pour définir les valeurs des attributs pour l'objet PDOStatement que cette méthode retourne. Vous pouvez utiliser ceci pour définir la valeur PDO::ATTR_CURSOR à PDO::CURSOR_SCROLL pour demander un curseur scrollable. Quelques pilotes ont des options spécifiques qui peuvent être définies au moment de la préparation.
Valeurs de retour
Si le serveur de base de données prépare avec succès cette requête, PDO::prepare() retourne un objet PDOStatement. Si le serveur de base de données ne réussit pas à préparer la requête, PDO::prepare() retourne FALSE.
Note: L'émulation de requêtes préparées ne communique pas avec le serveur de base de données. Aussi, la fonction PDO::prepare() ne vérifie pas la requête.
Exemples
Exemple #1 Prépare une requête SQL avec des paramètres nommés
<?php
/* Exécute une requête préparée en passant un tableau de valeurs */
$sql = 'SELECT nom, couleur, calories
FROM fruit
WHERE calories < :calories AND couleur = :couleur';
$sth = $dbh->prepare($sql, array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY));
$sth->execute(array(':calories' => 150, ':couleur' => 'red'));
$red = $sth->fetchAll();
$sth->execute(array('calories' => 175, 'couleur' => 'yellow'));
$yellow = $sth->fetchAll();
?>
Exemple #2 Prépare une requête SQL avec des marqueurs
<?php
/* Exécute une requête préparée en passant un tableau de valeurs */
$sth = $dbh->prepare('SELECT nom, couleur, calories
FROM fruit
WHERE calories < ? AND couleur = ?');
$sth->execute(array(150, 'rouge'));
$red = $sth->fetchAll();
$sth->execute(array(175, 'jaune'));
$yellow = $sth->fetchAll();
?>
Voir aussi
- PDO::exec() - Exécute une requête SQL et retourne le nombre de lignes affectées
- PDO::query() - Exécute une requête SQL, retourne un jeu de résultats en tant qu'objet PDOStatement
- PDOStatement::execute() - Exécute une requête préparée
PDO::prepare
29-Oct-2009 11:15
11-Sep-2009 11:44
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.
24-May-2009 08:06
In addition to what "admin at wdfa dot co dot uk" said, 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().
10-Apr-2009 04:52
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'
26-Sep-2008 10:25
@ jacques at chester dot id dot au
If your table names are configurable (and came from a safe source, like your own config), you can easily use string concatenation to put them in a query.
If the source is unknown / unsafe, it's usually a sign of terrible design flaws. in example if you have N tables with the same set of fields, it would be much safer to make just two tables - mark (containing list of names of what "used to be" old tables) and real data (with one more column referencing key). Then, all operations on data can be performed using the db user unable to delete all your data, and (the point this all started) you know names of both tables when preparing statement, so no problem with PDO not converting/escaping it properly.
Only exception is when you're writing DB management system. Then, however, user is supported to have access to everything db user has, so SQL Injection is a cese of no gain == no problem.
As far as I understand, those were main reason nobody even thought that serious developer will need functioning table names sql injection prevention so near to db drivers.
19-May-2008 05:16
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;
?>
14-Nov-2007 03:35
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.
07-Apr-2007 01:41
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
23-Feb-2007 06:51
A more versatile version of the below, but supporting an associative array and arbitrary number of fields:
<?php
public function matchCriteria($fields=null) {
$db=DB::conn();
$sql=array();
$paramArray=array();
if(is_array($fields)) {
foreach ($fields as $field=>$value)) {
$sql[] = $field.'=?';
$paramArray[]=$value;
}
}
$rs=$db->prepare('SELECT * FROM mytable'.(count($paramArray) ? ' WHERE '.join(' AND ',$sql) : ''));
$result=$rs->execute($paramArray);
if($result) {
return $rs;
}
return false;
}
?>
22-Feb-2007 04:03
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;
}
?>
13-Nov-2006 02:07
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.
31-Aug-2006 10:58
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)
30-Aug-2006 08:58
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.
