PHP: MySQL-tillägget är avvecklat

• Utgått sedan PHP 5, 5 ... gått i PHP 7.0
• En dålig design
  • Mer än 15 års existens
  • DB-anslutningar: den sista är standard-en
  • Felhantering? Vilken felhantering?
  • Designad för MySQL 3.23
  • Krypterade anslutningar
  • Inga beredda uttalanden
• En fara för framtiden
  • Snart upprätthålls inte längre
• Så, vad ska du använda?
• Sprid ordet

PHP är ett underbart webbserverns programmeringsspråk, men det är inte bra att lagra strukturerad data ensam. Det är därför det har tillägg, som kan ansluta till och använda DBMS (DataBase Management Systems), inklusive den populära MySQL . Det är en respektabel DB-motor med aktiv utveckling och populär användning, särskilt i [W / L / M] AMP-inställningar.

Däremot är dess användning i PHP (historiskt) gjort via PHP MySQL-tillägget (

 mysql_ * 

funktioner), som är föråldrad och avlägsnad! (Blanda inte: MySQL själv är inte avskriven)

Brace dig själv, den här artikeln är lite lång ... Om du inte vill läsa, kom ihåg bara det här: förbjud allt

 mysql_ * 

funktioner och använd mysql i eller PDO.

Utgått sedan PHP 5, 5 ... gått i PHP 7.0

PHP 5.5.0 publicerades officiellt den 20 juni 2013 (se nyhetsarkivet PHP, inklusive releasenoteringar). I den här versionen beslutade PHP-utvecklarna att avskriva MySQL-tillägget.

Flera skäl till det har uttryckts på beslutets RFC-sida. Denna FAQ-artikel summerar dem.

Också, sedan PHP 7.0, har förlängningen helt tagits bort, eftersom den var obestämd och blev oförenlig med den nya versionen av språket runtime.

Så, vem säger deprecated, säger att det finns goda skäl att inte använda den längre. Bara så du glömmer inte någon

 mysql_ * 

Funktionsanvändning utlöser a

 E_DEPRECATED 

varning (inte fel) som standard i PHP 5.5+.

En dålig design

Mer än 15 års existens

MySQL-tillägget introducerades i PHP 2.0, det var redan före 1998, år PHP 3 släpptes. 15 år gammal programmeringsteknik är inte alltid effektiv idag, ännu mer i IT, som utvecklas mycket snabbt. Det kan förklara dess (relativ) långsamhet jämfört med andra DBMS-förlängningar ... och förklarar också bristen på vissa funktioner som är viktiga för dagens användning, som beskrivs nedan.

DB-anslutningar: den sista är standard-en

 mysql_ * 

funktioner, om du inte uttryckligen berättade det, anser du att DB-anslutningen ska användas är den senast öppnade. Detta beteende är problematiskt i två fall:

• när du använder flera DB: er samtidigt: glöm inte att skicka anslutningsparametern, och din SQL-förfrågan går i fel DB.
• att spåra fel: ingen variabel beskriver explicit anslutningen, så det är omöjligt att använda en PHP IDE / debugger: du måste hitta den inkriminerade

   mysql_connect 

  själv och lägg till debugging code om det är nödvändigt.

Felhantering? Vilken felhantering?

PHP 5 ger ett paradigm som tagits direkt från Objektorienterad programmering: undantag. MySQL-förlängningen är för gammal och har aldrig uppdaterats för att använda dem, så det enda sättet att fånga fel är att använda mysql_error (). Stor nackdel med denna teknik: du måste sätta din felhanteringskod efter varje

 mysql_ * 

funktionssamtal!

Undantag gör att ett kodblock kan avbrytas och gå direkt till felhanteringen, förenkla koden inte bara för programmeraren utan också för PHP: Undantag är passiva och utlöses endast när en funktion rapporterar ett fel i sig. Med det andra tillvägagångssättet måste PHP kontrollera varje gång om allt gick som planerat, och mestadels gjorde det ... det är värdelöst arbete.

Designad för MySQL 3.23

Fler avancerade (My) SQL-användare kommer att bli besvikna: vissa funktioner som utvecklats efter 3.23 är helt enkelt inte tillgängliga, på grund av bristen på lämpliga uppdateringar.

Detta resulterar i bristen på SQL-procedurer, som i vissa fall är mycket användbara.

Enligt vissa personer har utvidgningen också problem med vissa textkodningar.

Krypterade anslutningar

Fjärr DB-anslutningar kan säkras med SSL (Secure Socket Layer), men inte TLS (Transport Layer Security). Som några senaste händelser har bevisat (som skrivet, OpenSSLs HeartBleed) SSL att vara ett trasigt protokoll och bör ersättas av TLS 1.1+ av många skäl som inte kommer att förklaras här. Utvidgningen stöder inte TLS, vilket alltså kräver att alla använder en krypteringsstandard som också bör betraktas som avskriven.

Inga beredda uttalanden

Har du märkt den djärva och underrubriken? Detta är förmodligen den viktigaste punkten i hela denna artikel:

MySQL-anknytningen har inga förberedda uttalanden .

Whazzat, och varför är de så viktiga? SQL-förfrågningar är det mesta av tidsvariabeln enligt användarens val; Den enklaste (och tyvärr mest utbredda) lösningen ser ut så här:

 mysql_query ('UPDATE-medlemmar SET name = "'. $ _ GET ['name']. '" VAR NÄR = "'. $ namn. '"'); 

Allt är bra, du lägger dubbla citat runt användarens data. Synd, det är långt ifrån tillräckligt: ​​alla användare kan bli administratörer genom att komma åt

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

. Vissa slumpmässiga handledning kommer att berätta att du ska använda

 mysql_real_escape_string 

, som även om det är effektivt, är (ärligt) överlångt och fult, och leder till förvirring och dubbel användning eller ingen användning alls på en given variabel.

Förberedda uttalanden ger en elegant lösning på denna röra: du förbereder din förfrågans struktur och kör den med de parametrar du vill ha (PDO-exempel):

 $ req = $ pdo-> förbereda ('UPDATE medlemmar SET namn =: nynamn VAR namn =: namn'); $ req-> execute (array ("newname" => $ _GET ['namn'], "namn" => $ namn)); 

Här går du utan att behöva oroa dig för SQL-injektioner. Allt det smutsiga arbetet är gjort för dig.

En fara för framtiden

Utvidgningen går farligt nära slutet av livet, dess borttagning från PHP är nära och din webbplats också om den använder den ... Ännu idag finns det en hel "kultur" runt förlängningen, som snart kommer att försvinna, utan att veta det: en stora tutorials och människor rekommenderar fortfarande användningen, inte medveten om framtida borttagning. Du har det, den här kulturen måste torkas bort.

Därför måste du absolut konvertera dina skript, webbplatser eller till och med CMS (om det är möjligt) till ett annat DB Access API. Ju snabbare det är gjort, desto bättre: Ditt projekt är kanske inte stort (ännu), och dokumentationen till filändelsen är fortfarande lätt tillgänglig, liksom tutorials om konvertering.

Ovan nämnda designproblem gör förlängningen orolig att konvertera. Men när det är klart, om du måste översätta din kod till en annan DB-anslutningsdrivrutin kommer det sannolikt att bli enklare: moderna API-filer är alla (mer eller mindre) lika.

Snart upprätthålls inte längre

Bristande underhåll ger en stor risk: säkerhetsbrott som kommer att hittas i sin kod kommer nog aldrig att lösas. Om en kritisk säkerhetsproblem upptäcktes skulle det hota miljontals webbplatser om de inte gjorde omkopplaren. Försök att inte vara en av dem.

Så, vad ska du använda?

Svaret är enkelt, men välj dig:

• PDO
  • Objektorienterat gränssnitt
  • Arbeta med flera DBMS: MySQL, MSSQL, sqlite, ...
• mysqli
  • Korskompatibel objektorienterad och funktionell modell
  • Hänger ihop MySQL-tillägget

Sprid ordet

Om du ser någon som rådfrågar förlängningens användning eller lär dig att använda den, gör vad du kan för att berätta för honom / henne att han gör något fel:

berätta och länka honom / henne den här artikeln, som kommer att visa argument varför inte använda den, istället för att skriva ett långvarigt svar.

Denna FAQ artikel är licensierad under CC BY-SA och skrevs ursprungligen av gravgun.