PHP Mailing system

Uanset hvordan Zend formulerer det - politisk korrekt - så er det stadig en betingelse. I og med MySQL driveren udgår og erstattes af MySQLi, kan man notorisk ikke anbefale MySQL driveren. Derfor bliver "anbefalingen" at bruge en af to andre muligheder.
Skvadder/sludder eller ej, ser jeg det som, at når MySQL driveren udgår, bliver det hermed stillet som betingelse hvis du fortsat vil kunne forbinde til en MySQL database - dog med frit valg - at du må vælge mellem to muligheder. Ser du det som en anbefaling, er det fint. Jeg ser det dog stadig som en betingelse. Det er et spørgsmål om holdning.

der er sikkerhedsrisici ved ubehandlet værdier/data, brugt direkte i SQL queries, som prepared statements ikke imødegår. Hvilke?

Fordelen ved prep. statements er muligheden for statements med parametre. Parameterized statements lukker nogle af hullerne omkring brug af ubehandlet værdier i SQL. Ved ikke at benytte denne fordel, kan du gå i klassiske fælder, som opstår ved SQLI (f.eks. "AND 1=1;#"), typisk med ubehandlet data fra bruger input.

Til dine betragtninger vedr. performance, henholder jeg blot til mysql.com, Zend og egne (og såmænd også andres) erfaringer: I rigtig mange situationer er prepared statements (PDO eller MySQLI) væsentligt hurtigere end det gamle MySQL-API. I andre situationer er det marginalt langsommere.

Enten har jeg formuleret mig forkert, eller du må have misforstået min formulering. Jeg mener dog at have forklaret hvorfor prep. statements er hurtigere, hvorfor jeg ikke forstå din misforståelse.
Jeg er enig i, at den gamle MySQL driver er langsommere end MySQLi. Det er netop derfor MySQLi blev skrevet. MySQLi er skrevet ind i PHP5, og er ikke længere er en extension som MySQL er til PHP4. Min formulering gik dog på at PDO_MYSQL er langsommere end MySQLi API. Forklaring kan findes i tidligere indlæg, men gentages gerne: Årsagen er at du benytter et abstraktionslag, frem for at gå direkte til kilden. Det er dog igen en opvejning, vil du have performance, eller vil du have kode der er nem at flytte.

Men i nogle enkeltstående situationer vinder du både hastighed og RAM.

Helt korrekt - og der er da ingen, som kan garantere, vi ikke kommer til dén diskusion en dag. I nærværende tråd kan vi dog nøjes med de forhold, som gør sig gældende for de situationer, vi taler om her.

I nærværende tråd, er det mindre relevant kontra andre problemstillinger.

Nu bliver du godt nok avanceret!

Zend lader MySQL-API'et udgå. Mon det sker, fordi de finder det anbefalelsesværdigt at anvende? Eller mon de gør det, fordi de mener, at MySQLI ('I' for 'improved') og PDO er at anbefale? De har længe anbefalet at anvende prepared statements fremfor mysql_real_escape_string - også før, MySQL-API'et blev deprecated.

Uanset, hvordan du formulerer dig, finder jeg Zends mindre forvrøvlet =)

Parameterized statements lukker nogle af hullerne omkring brug af ubehandlet værdier i SQL

Ja, det har du fortalt mange gange. Én gang mere end jeg har spurgt om, hvilke af disse huller prepared statements ikke lukker. Lad mig bare spørge en gang til, så vi 'står lige' =)

Nu bliver du godt nok avanceret!

Det kan gerne være. Og det kan gerne være at det er vrøvl, eller flueknep. Men en anbefaling går stadig på at man har lige muligheder for vælge mellem MySQL, MySQLI eller PDO, når man arbejder med MySQL DB. Det har man ikke længere, fordi MySQL driver udgår, ergo kan det ikke være en anbefaling, men derimod bliver det en betingelse for arbejdet.

Parameterized statements lukker nogle af hullerne omkring brug af ubehandlet værdier i SQL

Ja, det har du fortalt mange gange. Én gang mere end jeg har spurgt om, hvilke af disse huller prepared statements ikke lukker. Lad mig bare spørge en gang til, så vi 'står lige' =)

Da det åbenbart er svært at lure. Må jeg igen svare, som jeg tidl. har svaret. Prep. statements lukker ikke huller skabt ved brug af ubehandlet data i SQL, der kan forårsage SQLI.

Antag $_GET['val'] = 'AND 1=1;#'
og 'DELETE FROM table WHERE value = '.$_GET['val'].' AND value NOT NULL';

Om du udfører $sql med mysql, mysqli eller PDO, prepared eller ej, vil dette være et sikkerhedshul skabt med SQLI.

Bruger du para. statements:
'DELETE FROM table WHERE value = ? AND value NOT NULL';

og sender $_GET['val'] som parameter til ?-tegnet, vil du undgå ovenstående SQLI sikkerhedshul. Fordi PDO og MySQLi har indbygget databehandling - escaping (hvis det ikke skulle være luret ).