PHP: l'estensione MySQL è deprecata

Obsoleto da PHP 5.5 ... andato in PHP 7.0
Un cattivo design
- Più di 15 anni di esistenza
- Connessioni DB: l'ultima è quella predefinita
- Gestione degli errori? Che errore gestisce?
- Progettato per MySQL 3.23
- Connessioni crittografate
- Nessuna dichiarazione preparata
Un pericolo per il futuro
- Presto non mantenuto più
Quindi, cosa usare?
Diffondere la parola

PHP è un meraviglioso linguaggio di programmazione per server web, ma non è eccezionale per archiviare da solo i dati strutturati. Ecco perché ha estensioni, che possono connettersi e utilizzare DBMS (DataBase Management Systems), tra cui il popolare MySQL . È un motore DB rispettabile, con sviluppo attivo e utilizzo diffuso, specialmente nelle configurazioni AMP [W / L / M].

Tuttavia, il suo uso in PHP è (storicamente) fatto tramite l'estensione PHP MySQL (

 mysql_ *

funzioni), che è obsoleto e deprecato! (Non confondere: MySQL stesso non è deprecato)

Preparati, questo articolo è un po 'lungo ... Se non vuoi leggere, ricordati di questo: vietare tutto

 mysql_ *

funzioni e usa mysql i o PDO.

Obsoleto da PHP 5.5 ... andato in PHP 7.0

PHP 5.5.0 è stato rilasciato ufficialmente il 20 giugno 2013 (vedi l'archivio delle notizie di PHP 2013, incluse le note di rilascio). In questa versione, gli sviluppatori PHP hanno deciso di deprecare l'estensione MySQL.

Molte ragioni sono state espresse sulla pagina RFC della decisione. Questo articolo delle domande frequenti li riassume.

Inoltre, dal PHP 7.0, l'estensione è stata completamente rimossa, in quanto non era mantenuta e non era compatibile con la nuova versione del runtime del linguaggio.

Quindi, chi dice deprecato, dice che ci sono buone ragioni per non usarlo più. Solo così non lo dimentichi, nessuno

 mysql_ *

l'uso della funzione attiverà a

 E_DEPRECATED

avviso (non errore) di default in PHP 5.5+.

Un cattivo design

Più di 15 anni di esistenza

L'estensione MySQL è stata introdotta in PHP 2.0, anche prima del 1998, l'anno in cui è stato rilasciato PHP 3. Le tecniche di programmazione di 15 anni non sono sempre efficienti fino ad oggi, ancor più nell'IT, che evolve molto velocemente. Ciò potrebbe spiegare la sua (relativa) lentezza rispetto ad altre estensioni DBMS ... e spiega anche la mancanza di alcune caratteristiche che sono importanti per l'uso di oggi, descritte di seguito.

Connessioni DB: l'ultima è quella predefinita

 mysql_ *

funzioni, se non viene detto esplicitamente, considerare la connessione DB da utilizzare è quella aperta più di recente. Questo comportamento è problematico in due casi:

quando si utilizzano più DB contemporaneamente: dimenticare di passare il parametro di connessione e la richiesta SQL va nel DB errato.
per rintracciare i bug: nessuna variabile descrive esplicitamente la connessione, quindi è impossibile usare un IDE / debugger PHP: devi trovare l'incriminato
```
 mysql_connect 
```
te stesso e aggiungi il codice di debug se è necessario.

Gestione degli errori? Che errore gestisce?

PHP 5 introduce un paradigma derivato direttamente dalla programmazione orientata agli oggetti: eccezioni. L'estensione MySQL è troppo vecchia e non è mai stata aggiornata per usarli, quindi l'unico modo per catturare gli errori è usare mysql_error (). Grande svantaggio di questa tecnica: è necessario inserire il codice di gestione degli errori dopo ogni

 mysql_ *

chiamata di funzione!

Le eccezioni consentono di interrompere un blocco di codice e passare direttamente alla gestione degli errori, semplificando il codice non solo per il programmatore, ma anche per PHP: le eccezioni sono passive e attivate solo quando una funzione segnala un errore di per sé. Con l'altro approccio, PHP deve controllare ogni volta se tutto è andato come previsto, e il più delle volte ha fatto ... è un lavoro inutile.

Progettato per MySQL 3.23

Gli utenti SQL più avanzati (My) saranno delusi: alcune funzionalità sviluppate dopo la 3.23 non sono semplicemente disponibili, a causa della mancanza di aggiornamenti di estensione appropriati.

Ciò si traduce nella mancanza di procedure SQL, che sono molto utili in alcuni casi.

Secondo alcune persone, l'estensione ha anche problemi con alcune codifiche di testo.

Connessioni crittografate

Le connessioni DB remote possono essere protette tramite SSL (Secure Socket Layer), ma non TLS (Transport Layer Security). Come alcuni recenti eventi hanno dimostrato (come nel caso della scrittura, OpenSSL's HeartBleed) SSL come un protocollo non funzionante, e dovrebbe essere sostituito da TLS 1.1+ per molte ragioni che non verranno spiegate qui. L'estensione non supporta TLS, quindi obbliga tutti a utilizzare uno standard di crittografia che dovrebbe essere considerato deprecato.

Nessuna dichiarazione preparata

Hai notato il titolo audace e sottolineato? Questo è probabilmente il punto più importante di questo intero articolo:

L'estensione MySQL non ha dichiarazioni preparate .

Whazzat, e perché sono così importanti? Le richieste SQL sono la maggior parte delle variabili del tempo in base alle scelte dell'utente; la soluzione più semplice (e purtroppo più diffusa) si presenta così:

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

Va tutto bene, metti le doppie virgolette sui dati dell'utente. Peccato, questo è tutt'altro che sufficiente: qualsiasi utente può diventare un amministratore accedendo

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

. Alcuni tutorial casuali ti diranno di usarli

 mysql_real_escape_string

, che anche se è efficiente, è (onestamente) troppo lungo e brutto, e porta alla confusione e al doppio uso o a nessun uso su una determinata variabile.

Le istruzioni preparate forniscono una soluzione elegante a questo pasticcio: si prepara la struttura della richiesta, quindi la si esegue con i parametri che si desidera (esempio PDO):

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

Ecco qua, senza mai doversi preoccupare delle iniezioni SQL. Tutto il lavoro sporco è fatto per te.

Un pericolo per il futuro

L'estensione si avvicina pericolosamente alla sua fine della vita, la sua cancellazione da PHP è imminente, e anche il tuo sito se lo usa ... Ancora oggi c'è un'intera "cultura" intorno all'estensione, che presto sparirà, senza saperlo: un Un sacco di tutorial e persone raccomandano ancora il suo uso, non consapevoli della sua futura rimozione. Hai capito, questa cultura deve essere spazzata via.

Ecco perché è assolutamente necessario convertire script, siti Web o anche CMS (se possibile) in un'altra API di accesso DB. Quanto prima è fatto, tanto meglio: il tuo progetto forse non è grande (ancora), e la documentazione dell'estensione è ancora facilmente disponibile, così come le esercitazioni sulla conversione.

I problemi di progettazione sopra menzionati rendono l'estensione difficile da convertire. Ma una volta fatto, se è necessario convertire il codice in un altro driver di connessione DB, sarà probabilmente più semplice: le API moderne sono tutte (più o meno) simili.

Presto non mantenuto più

La mancanza di manutenzione comporta un rischio maggiore: le violazioni della sicurezza che si troveranno nel suo codice probabilmente non verranno mai corrette. Se fosse stato scoperto un problema di sicurezza critico, ciò avrebbe minacciato milioni di siti Web se non avessero effettuato il passaggio. Cerca di non essere uno di loro.

Quindi, cosa usare?

La risposta è semplice, ma fai la tua scelta:

DOP
- Solo interfaccia orientata agli oggetti
- Lavora con più DBMS: MySQL, MSSQL, sqlite, ...
mysqli
- Modello orientato agli oggetti e funzionale compatibile
- Higly assomiglia all'estensione MySQL