PHP: de MySQL-extensie is verouderd

• Vervallen sinds PHP 5.5 ... verdwenen in PHP 7.0
• Een slecht ontwerp
  • Meer dan 15 jaar van bestaan
  • DB-verbindingen: de laatste is de standaard
  • Foutafhandeling? Welke foutafhandeling?
  • Ontworpen voor MySQL 3.23
  • Versleutelde verbindingen
  • Geen voorbereide verklaringen
• Een gevaar voor de toekomst
  • Al snel niet meer onderhouden
• Dus, wat te gebruiken?
• Vertel het verder

PHP is een prachtige webserver programmeertaal, maar het is niet geweldig om gestructureerde gegevens alleen op te slaan. Dat is waarom het uitbreidingen heeft, die verbinding kunnen maken met en gebruik maken van DBMSs (DataBase Management Systems), inclusief de populaire MySQL . Het is een respectabele DB-engine, met actieve ontwikkeling en populair gebruik, vooral in AMP-setups [W / L / M].

Het gebruik ervan in PHP wordt echter (historisch gezien) gedaan via de PHP MySQL-extensie (

 mysql_ * 

functies), die verouderd en verouderd is! (Niet verwarren: MySQL zelf is niet verouderd)

Zet je schrap, dit artikel is een beetje lang ... Als je niet wilt lezen, onthoud dit: verbied allemaal

 mysql_ * 

functies en gebruik mysql i of PDO.

Vervallen sinds PHP 5.5 ... verdwenen in PHP 7.0

PHP 5.5.0 werd officieel vrijgegeven op 20 juni 2013 (zie het 2013 PHP nieuwsarchief, inclusief release notes). In deze versie besloten de PHP-ontwikkelaars om de MySQL-extensie te beëindigen.

Meerdere redenen hiervoor zijn op de RFC-pagina van de beslissing weergegeven. Dit FAQ-artikel somt ze op.

Sinds PHP 7.0 is de extensie ook volledig verwijderd, omdat deze niet werd onderhouden en onverenigbaar werd met de nieuwe versie van de runtime van de taal.

Dus, die zegt gedeprecieerd, zegt dat er goede redenen zijn om het niet meer te gebruiken. Alleen zodat je het niet vergeet

 mysql_ * 

functiegebruik activeert a

 E_DEPRECATED 

waarschuwing (niet fout) standaard in PHP 5.5+.

Een slecht ontwerp

Meer dan 15 jaar van bestaan

De MySQL-extensie is geïntroduceerd in PHP 2.0, dat is nog voor 1998, het jaar waarin PHP 3 werd uitgebracht. 15 jaar oude programmeertechnieken zijn vanaf vandaag niet altijd efficiënt, meer nog niet in IT, die erg snel evolueert. Dat zou de (relatieve) traagheid kunnen verklaren in vergelijking met andere DBMS-extensies ... en verklaart ook het ontbreken van een aantal functies die belangrijk zijn voor het gebruik van vandaag, zoals hieronder beschreven.

DB-verbindingen: de laatste is de standaard

 mysql_ * 

functies, indien niet expliciet verteld, zijn van mening dat de DB-verbinding die wordt gebruikt de meest recent geopende is. Dit gedrag is problematisch in twee gevallen:

• wanneer u meerdere DB's tegelijkertijd gebruikt: vergeet de verbindingsparameter door te geven, en uw SQL-verzoek komt in de verkeerde DB.
• om bugs te volgen: geen variabele beschrijft de verbinding expliciet, dus het is onmogelijk om een ​​PHP IDE / debugger te gebruiken: je moet de beschuldigde vinden

   mysql_connect 

  zelf en voeg debugging code toe als dat nodig is.

Foutafhandeling? Welke foutafhandeling?

PHP 5 brengt een paradigma dat rechtstreeks uit Object-Oriented programming komt: uitzonderingen. De MySQL-extensie is te oud en is nooit bijgewerkt om ze te gebruiken, dus de enige manier om fouten te vangen is door mysql_error () te gebruiken. Groot nadeel van deze techniek: u moet uw foutafhandelingscode na elk zetten

 mysql_ * 

functieaanroep!

Met uitzonderingen kan een codeblok worden onderbroken en direct naar de foutafhandeling gaan, waardoor de code niet alleen voor de programmeur, maar ook voor PHP wordt vereenvoudigd: uitzonderingen zijn passief en worden alleen geactiveerd als een functie zelf een fout meldt. Met de andere benadering moet PHP elke keer controleren of alles volgens plan verloopt, en meestal deed het dat ... dat is nutteloos werk.

Ontworpen voor MySQL 3.23

Meer geavanceerde (My) SQL-gebruikers zullen teleurgesteld zijn: sommige functies die na 3.23 zijn ontwikkeld, zijn simpelweg niet beschikbaar vanwege het ontbreken van geschikte uitbreidingsupdates.

Dit resulteert in het ontbreken van SQL-procedures, die in sommige gevallen zeer nuttig zijn.

Volgens sommigen heeft de extensie ook problemen met sommige tekstcoderingen.

Versleutelde verbindingen

Externe DB-verbindingen kunnen worden beveiligd met SSL (Secure Socket Layer), maar niet met TLS (Transport Layer Security). Zoals enkele recente gebeurtenissen hebben bewezen (zoals schrijven, is OpenSSL's HeartBleed) SSL een verbroken protocol en moeten ze worden vervangen door TLS 1.1+ om tal van redenen die hier niet worden uitgelegd. De extensie ondersteunt TLS niet, dwingt daarom iedereen een coderingsstandaard te gebruiken die ook als verouderd moet worden beschouwd.

Geen voorbereide verklaringen

Heb je de vetgedrukte en onderstreepte titel opgemerkt? Dit is waarschijnlijk het belangrijkste punt van dit hele artikel:

De MySQL-extensie heeft geen voorbereide instructies .

Whazzat, en waarom zijn ze zo belangrijk? SQL-verzoeken zijn meestal afhankelijk van de keuzes van de gebruiker; de eenvoudigste (en helaas meest voorkomende) oplossing ziet er als volgt uit:

 mysql_query ('UPDATE leden SET name = "'. $ _ GET ['name']. '" WHERE name = "'. $ name. '"'); 

Alles is in orde, je plaatst dubbele aanhalingstekens rond de gegevens van de gebruiker. Jammer, dat is verre van voldoende: elke gebruiker kan beheerder worden door toegang te krijgen

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

. Sommige willekeurige tutorial zal je vertellen om te gebruiken

 mysql_real_escape_string 

, zelfs als het efficiënt is, (eerlijk) te lang en lelijk is en leidt tot verwarring en dubbel gebruik of helemaal geen gebruik van een gegeven variabele.

De voorbereide verklaringen bieden een elegante oplossing voor deze puinhoop: u bereidt de structuur van uw aanvraag voor en voert deze vervolgens uit met de gewenste parameters (PDO-voorbeeld):

 $ req = $ pdo-> prepare ('UPDATE leden SET name =: newname WHERE name =: name'); $ req-> execute (array ("newname" => $ _GET ['name'], "name" => $ name)); 

Hier ga je, zonder je ooit zorgen te hoeven maken over SQL-injecties. Al het vuile werk is voor je gedaan.

Een gevaar voor de toekomst

De extensie nadert gevaarlijk het einde van zijn levensduur, de verwijdering uit PHP is aanstaande, en jouw site ook als deze wordt gebruikt ... Zelfs vandaag is er een hele "cultuur" rondom de extensie, die snel zal verdwijnen, zonder het te weten: een enorm veel tutorials en mensen raden het gebruik ervan nog steeds aan, niet op de hoogte van de toekomstige verwijdering ervan. Je snapt het, deze cultuur moet worden weggevaagd.

Daarom moet u uw scripts, websites of zelfs CMS's (als het mogelijk is) absoluut naar een andere DB-toegang-API converteren. Hoe eerder het gedaan is, hoe beter: uw project is misschien (nog) niet groot en de documentatie van de extensie is nog steeds gemakkelijk beschikbaar, net als tutorials over het converteren.

Bovengenoemde ontwerpproblemen maken de extensie ongemakkelijk om te converteren. Maar als dat eenmaal is gebeurd, als u uw code naar een ander DB-verbindingsstuurprogramma moet vertalen, is dit waarschijnlijk eenvoudiger: moderne API's zijn allemaal (min of meer) hetzelfde.

Al snel niet meer onderhouden

Gebrek aan onderhoud brengt een groot risico met zich mee: beveiligingsinbreuken die in de code worden aangetroffen, zullen waarschijnlijk nooit worden verholpen. Als een kritiek beveiligingsprobleem werd ontdekt, zou dat miljoenen websites bedreigen als ze de overstap niet maakten. Probeer niet een van hen te zijn.

Dus, wat te gebruiken?

Het antwoord is eenvoudig, maar maak je keuze:

• BOB
  • Object-georiënteerde interface alleen
  • Werk met meerdere DBMS's: MySQL, MSSQL, SQLite, ...
• mysqli
  • Cross-compatibel objectgericht en functioneel model
  • Het lijkt sterk op de MySQL-extensie

Vertel het verder

Als u iemand ziet die adviseert het gebruik van de extensie te gebruiken of het te leren gebruiken, doe dan wat u kunt om hem of haar te vertellen dat hij iets verkeerd doet:

vertel en link hem / haar dit artikel, dat argumenten zal tonen waarom het niet gebruikt moet worden, in plaats van een lang en kieskeurig antwoord te schrijven.

Dit FAQ-artikel is gelicentieerd onder CC BY-SA en werd oorspronkelijk geschreven door gravgun.