I've been told that I'd be better using PDO
for MySQL escaping, rather than mysql_real_escape_string
.
Maybe I'm having a brain-dead day (or it may be the fact I'm by no stretch of the imagination a natural programmer, and I'm still very much at the newbie stage when it comes to PHP), but having checked out the PHP manual and read the entry on PDO, I'm still no clearer as to what PDO actually is and why it's better than using mysql_real_escape_string
. This may be because I've not really got to grips with the complexities of OOP yet (I'm assuming it's something to do with OOP), but other than the fact that variables and array values seem to have a colon infront of them, I'm still not sure what it actually is and how you use it (and why it's better than mysql_real_escape_string
. (It also may have something to do with the fact that I don't really have a clear understanding of what 'classes' are, so when I read "PDO class" I'm none the wiser really).
Having read an article or two on the 'Developer Zone' bit of the MySQL website, I'm still no clearer. As I can't even figure out what it is at the moment, I think probably using it is a bit beyond me right now, but I'm still interested in broadening my education and finding out how I could improve things.
Could anyone explain to me in 'plain English' what PDO is (or point me in the direction of something on the subject written in plain English), and how you'd go about using it?
Both MySQLi and PDO have their advantages: PDO will work on 12 different database systems, whereas MySQLi will only work with MySQL databases. So, if you have to switch your project to use another database, PDO makes the process easy. You only have to change the connection string and a few queries.
The main advantage of PDO over MySQLi is in the database support. PDO supports 12 different database types, in opposition to MySQLi, which supports MySQL only. When you have to switch your project to use another database, PDO makes the process simpler.
As the current answers go into details while your question is more aimed at a general overview, I'll give it a try:
The PDO classes aim to encapsulate all the functionality needed to interact with a database. They do this by defining 'methods' (OO parlor for functions) and 'properties' (OO parlor for variables). You'd use them as a complete replacement for all the 'standard' functions you are using now for talking to a database.
So instead of calling a series of the 'mysql_doSomething()' functions, storing their results in your own variables, you would 'instantiate' an object from the PDO class ('class' = abstract definition, 'object' = concrete, usable instance of a class) and call methods on that object to do the same.
As an example, without PDO, you'd do something like this:
// Get a db connection $connection = mysql_connect('someHost/someDB', 'userName', 'password'); // Prepare a query $query = "SELECT * FROM someTable WHERE something = " . mysql_real_escape_string($comparison) . "'"; // Issue a query $db_result = mysql_query($query); // Fetch the results $results = array(); while ($row = mysql_fetch_array($db_result)) { $results[] = $row; }
while this would be the equivalent using PDO:
// Instantiate new PDO object (will create connection on the fly) $db = new PDO('mysql:dbname=someDB;host=someHost'); // Prepare a query (will escape on the fly) $statement = $db->prepare('SELECT * FROM someTable WHERE something = :comparison'); // $statement is now a PDOStatement object, with its own methods to use it, e.g. // execute the query, passing in the parameters to replace $statement->execute(array(':comparison' => $comparison)); // fetch results as array $results = $statement->fetchAll();
So on first glance, there is not much difference, except in syntax. But the PDO version has some advantages, the biggest one being database independence:
If you need to talk to a PostgreSQL database instead, you'd only change mysql:
to pgsql:
in the instantiating call new PDO()
. With the old method, you'd have to go through all your code, replacing all 'mysql_doSomething()' functions with their 'pg_doSomthing()' counterpart (always checking for potential differences in parameter handling). The same would be the case for many other supported database engines.
So to get back to your question, PDO basically just gives you a different way to achieve the same things, while offering some shortcuts/improvements/advantages. For example, escaping would happen automatically in the proper way needed for the database engine you are using. Also parameter substitution (prevents SQL Injections, not shown in example) is much easier, making it less error prone.
You should read up on some OOP basics to get an idea of other advantages.
I'm not super familiar with PDO, but there is a distinction between "prepared statements" and escaped strings. Escaping is about removing disallowed character strings from the query, but prepared statements are about telling the database what kind of query to expect.
Think of it this way: when you give a query to the database, you're telling it several separate things. One thing might be, for example, "I want you to do a select." Another might be "limit it to rows WHERE the user name is the following value."
If you build up a query as a string and hand it to the database, it doesn't know about either part until it gets the completed string. You might do this:
'SELECT * FROM transactions WHERE username=$username'
When it gets that string, it has to parse it and decide "this is a SELECT
with a WHERE
".
Suppose a malicious user inputs their user name as billysmith OR 1=1
. If you're not careful, you might put that into your string, resulting in:
'SELECT * FROM transactions WHERE username=billysmith OR 1=1'
...which would return all the transactions for all users, because 1 always equals 1. Whoops, you've been hacked!
See what happened? The database didn't know what parts to expect in your query, so it just parsed the string. It wasn't surprised that the WHERE
had an OR
, with two conditions that could satisfy it.
If only it had known what to expect, namely, a SELECT
whose WHERE
had only one condition, the malicious user couldn't have tricked it.
With a prepared statement, you can give it that correct expectation. You you can tell the database "I'm about to send you a SELECT
, and it's going to be limited to rows WHERE username =
a string that I'm about to give you. That's all - there are no other parts to the query. Are you ready? OK, here comes the string to compare to the username."
With that expectation, the database wouldn't be fooled: it would only return rows where the username
column contains the actual string 'billysmith OR 1=1.' If nobody has that user name, it would return nothing.
In addition to security benefits, prepared statements have a couple of speed benefits:
For another explanation, see Theo's answer here.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With