$stmt = $somePDOObject->prepare("INSERT INTO folks " .
"(name, addr, city) values (:name, :addr, :city);");
$stmt->bindValue(":name", $name);
$stmt->bindValue(":addr", $addr);
$stmt->bindValue(":city", $city);
Slightly more verbose, but it has the upside of being more resilient. $stmt = $somePDOObject->prepare("INSERT INTO folks " .
"(name, addr, city) values (:name, :addr, :city);");
$stmt->execute(
array(
":name" => $name,
":addr" => $addr,
":city" => $city));
since it treats the statement as a function call, rather than some chunk of state that you manipulate.Meh. Prepared statements are useful when you'll use the it multiple times through rebinding, and for one-shots it's easy enough to have a function taking a parameterized query and an array and doing the annoying crap internally.
Then you just write:
$result = executeSQL($somePDOObject,
"INSERT INTO folks (name, addr, city) values (:name, :addr, :city);",
array("name" => $name, "addr" => $addr, "city" => $city);No, or he would have mentioned it.
It's clearer (especially as the number of parameters increase) and easier to change (in order to e.g. add a new parameter)
Named parameters also make it easier to re-use queries (have a queries file or something) because you're much less apt to immediately break something by changing a query if everything is explicitly bound via names. And you can make the statements as a whole more terse if you'd like; I intentionally wrote it verbosely.
In your example, you have one place where you have position based binding that you could break while reusing or refactoring.
There's also the proclivity for people to want to reuse the same value in multiple places in a query. Name-based binding makes that a lot more readable and straightforward.
Think fast: is everything in the code below correct? I've already forgotten whether I've added an extra ? or left one off, and I just typed this 30 seconds ago.
$sth = $dbh->("INSERT INTO a_table (lorem, ipsum, dolor, sit, amet, consectetur, adipiscing, elit, donec, malesuada, purus, et, tellus, dignissim, tristique, in, ipsum, neque, ultricies, quis, hendrerit, ac, pulvinar, eget, enim)
) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?);");
$sth->execute(array($lorem, $ipsum, $dolor, $sit, $amet, $consectetur, $adipiscing, $elit, $donec, $malesuada, $purus, $et, $tellus, $dignissim, $tristique, $in, $ipsum, $neque, $ultricies, $quis, $hendrerit, $ac, $pulvinar, $enim, $eget));also, the named version above can have query length issues I think.
Not to mention, "PHP: The Good Parts". I almost threw that book out when I hit those parts.
In Rails I'd write:
Folk.create(:name => some_name, :addr => some_addr, :city => some_city)
One line, easily readable and only one language (Ruby).This is not meant to be a flame post - I'm just asking: Is it the preferred way in PHP to prepare SQL statements yourself?
I don't think RoR vs PHP would be an apples to apples comparison.
Do you not understand why you can't compare Rails (framework) to PHP (language)?
PHP has frameworks with ORM, too.
No 'serious hindrance' involved.
If we had trained people to simply do
in 2005, when PDO first came out, uncountable SQLI bugs would have been avoided, and maybe lulzsec wouldn't be having such a field day in 2011...