PHP: MySQL-utvidelsen er utdatert

Utdatert siden PHP 5.5 ... gått i PHP 7.0
En dårlig design
- Mer enn 15 års eksistens
- DB-tilkoblinger: Den siste er standard en
- Feilhåndtering? Hvilken feilhåndtering?
- Designet for MySQL 3.23
- Krypterte forbindelser
- Ingen forberedte uttalelser
En fare for fremtiden
- Snart opprettholdes ikke lenger
Så, hva skal du bruke?
Spre ordet

PHP er et fantastisk webserver programmeringsspråk, men det er ikke bra å lagre strukturerte data alene. Det er derfor det har utvidelser, som kan koble til og bruke DBMS (DataBase Management Systems), inkludert den populære MySQL . Det er en respektabel DB-motor, med aktiv utvikling og populær bruk, spesielt i [W / L / M] AMP-oppsett.

Imidlertid er bruken i PHP (historisk) gjort via PHP MySQL-utvidelsen (

 mysql_ *

funksjoner), som er foreldet og utdatert! (Ikke bland opp: MySQL i seg selv er ikke utdatert)

Brace deg selv, denne artikkelen er litt tad lenge ... Hvis du ikke vil lese, bare husk dette: forbud alle

 mysql_ *

Funksjoner og bruk mysql i eller PDO.

Utdatert siden PHP 5.5 ... gått i PHP 7.0

PHP 5.5.0 ble offisielt utgitt 20. juni 2013 (se PHP-nyhetsarkivet 2013, inkludert utgivelsesnotater). I denne versjonen bestemte PHP-utviklerne å avskrive MySQL-utvidelsen.

Flere årsaker til det har blitt uttrykt på beslutningens RFC-side. Denne FAQ-artikkelen summerer dem.

Dessuten, siden PHP 7.0, er utvidelsen helt fjernet, da den ble unhaintained og ble uforenlig med den nye versjonen av språket.

Så, som sier utdatert, sier det er gode grunner til ikke å bruke den lenger. Bare slik at du ikke glemmer noe

 mysql_ *

funksjon bruk vil utløse a

 E_DEPRECATED

advarsel (ikke feil) som standard i PHP 5.5+.

En dårlig design

Mer enn 15 års eksistens

MySQL-utvidelsen ble introdusert i PHP 2.0, det var allerede før 1998, ble PHP 3 utgitt. 15 år gamle programmeringsteknikker er ikke alltid effektive i dag, enda mer i IT, som utvikler seg veldig fort. Det kan forklare dens (relative) langsommelighet i forhold til andre DBMS-utvidelser ... og forklarer også mangelen på noen funksjoner som er viktige for dagens bruk, beskrevet nedenfor.

DB-tilkoblinger: Den siste er standard en

 mysql_ *

Funksjoner, hvis ikke fortalte eksplisitt, vurder DB-tilkoblingen til å bruke, er den sist åpnede. Denne oppførselen er problematisk i to tilfeller:

når du bruker flere DB'er samtidig: Glem å passere tilkoblingsparameteren, og SQL-forespørselen din går i feil DB.
å spore feil: ingen variabel beskriver eksplisitt forbindelsen, så det er umulig å bruke en PHP IDE / debugger: du må finne inkriminert
```
 mysql_connect 
```
selv og legg til feilsøkingskode hvis det er nødvendig.

Feilhåndtering? Hvilken feilhåndtering?

PHP 5 bringer et paradigme brakt fra objektorientert programmering: unntak. MySQL-utvidelsen er for gammel og har aldri blitt oppdatert for å bruke dem, så den eneste måten å fange feil på er å bruke mysql_error (). Stor ulemper til denne teknikken: Du må sette feilhåndterings-koden etter hver

 mysql_ *

funksjonsanrop!

Unntak gjør det mulig å avbryte en kodeblokk og gå rett til feilhåndteringen, forenkle koden ikke bare for programmereren, men også for PHP: unntakene er passive og utløses bare når en funksjon rapporterer en feil av seg selv. Med den andre tilnærmingen må PHP sjekke hver gang hvis alt gikk som planlagt, og mesteparten av tiden gjorde det ... det er ubrukelig arbeid.

Designet for MySQL 3.23

Flere avanserte (My) SQL-brukere vil bli skuffet: Noen funksjoner utviklet etter 3.23 er ganske enkelt ikke tilgjengelige, på grunn av mangel på passende utvidelsesoppdateringer.

Dette resulterer i mangel på SQL-prosedyrer, noe som er svært nyttig i noen tilfeller.

Ifølge noen har utvidelsen også problemer med noen tekstkodinger.

Krypterte forbindelser

Eksterne DB-tilkoblinger kan sikres ved hjelp av SSL (Secure Socket Layer), men ikke TLS (Transport Layer Security). Som noen nyere hendelser har vist (som skrevet, OpenSSLs HeartBleed) SSL å være en ødelagt protokoll, og bør erstattes av TLS 1.1+ av mange grunner som ikke vil bli forklart her. Utvidelsen støtter ikke TLS, derfor tvinger alle til å bruke en krypteringsstandard som også bør betraktes som utdatert.

Ingen forberedte uttalelser

Har du merket dristig og understreketittel? Dette er trolig det viktigste punktet i denne hele artikkelen:

MySQL-utvidelsen har ingen utarbeidede uttalelser .

Whazzat, og hvorfor er de så viktige? SQL-forespørsler er mesteparten av tidsvariabelen i henhold til brukerens valg; den enkleste (og dessverre mest utbredt) løsningen ser slik ut:

 mysql_query ('UPDATE medlemmer SET navn = "'. $ _ GET ['navn']. '" HVOR navn = "'. $ navn. '"');

Alt er greit, du legger dobbelt anførselstegn rundt brukerens data. Synd, det er langt fra tilstrekkelig: enhver bruker kan bli administrator ved å få tilgang

 endrings name.php? name =% 22% 20admin% 3D1% 20name% 3D% 22USERNAME

. Noen tilfeldig opplæring vil fortelle deg å bruke

 mysql_real_escape_string

, som selv om den er effektiv, er (ærlig) over-lang og stygg, og fører til forvirring og dobbelt bruk eller ingen bruk i det hele tatt på en gitt variabel.

Forberedte utsagn gir en elegant løsning på dette rotet: du forbereder forespørselsstrukturen din, og kjør den deretter med parametrene du vil ha (PDO-eksempel):

 $ req = $ pdo-> forberede ('UPDATE medlemmer SET navn =: nynavn HVOR navn =: navn'); $ req-> utfør (array ("newname" => $ _GET ['navn'], "navn" => $ navn));

Her går du uten å måtte bekymre deg for SQL-injeksjoner. Alt det skitne arbeidet er gjort for deg.

En fare for fremtiden

Utvidelsen farlig nærmer seg slutten av livet, dens sletting fra PHP er nært, og nettstedet ditt også hvis det bruker det ... Selv i dag er det en hel "kultur" rundt forlengelsen, som snart vil forsvinne uten å vite det: en mange tutorials og folk anbefaler fortsatt bruk, ikke klar over fremtidig fjerning. Du har det, denne kulturen må tørkes bort.

Derfor må du absolutt konvertere skript, nettsteder eller til og med CMS (hvis det er mulig) til en annen DB Access API. Jo raskere det er gjort, jo bedre: prosjektet ditt er kanskje ikke stort (enda), og utvidelsens dokumentasjon er fortsatt lett tilgjengelig, og det er opplæringsprogrammer om konvertering.

Ovennevnte designproblemer gjør utvidelsen ubehagelig å konvertere. Men når det er gjort, hvis du må oversette koden din til en annen DB-tilkoblingsdriver, vil det trolig være enklere: moderne APIer er alle (mer eller mindre) like.

Snart opprettholdes ikke lenger

Manglende vedlikehold gir en stor risiko: Sikkerhetsbrudd som vil bli funnet i koden, vil sannsynligvis aldri bli løst. Hvis et kritisk sikkerhetsproblem ble oppdaget, ville det true millioner av nettsteder hvis de ikke gjorde bryteren. Prøv å ikke være en av dem.

Så, hva skal du bruke?

Svaret er enkelt, men velg:

PUD
- Objektorientert grensesnitt
- Arbeid med flere DBMSer: MySQL, MSSQL, sqlite, ...
mysqli
- Kryss kompatibel objektorientert og funksjonell modell
- Helt nyter MySQL-utvidelsen