mysqli o DOP - quali sono i pro e i contro? [chiuso]

Al nostro posto siamo divisi tra l'uso di mysqli e PDO per cose come dichiarazioni preparate e supporto per le transazioni. Alcuni progetti ne usano uno, altri l'altro. Esistono poche probabilità realistiche di trasferirci in un altro RDBMS.

Preferisco il DOP per il solo motivo che consente parametri nominati per istruzioni preparate, e per quanto ne so mysqli non lo fa.

Ci sono altri pro e contro nella scelta l'uno rispetto all'altro come standard mentre consolidiamo i nostri progetti per usare solo un approccio?

Bene, potresti discutere con l'aspetto orientato agli oggetti, le dichiarazioni preparate, il fatto che diventi uno standard, ecc. Ma so che la maggior parte delle volte, convincere qualcuno a lavorare meglio con una caratteristica killer. Quindi eccolo:

Una cosa davvero bella con PDO è che puoi recuperare i dati, iniettandoli automaticamente in un oggetto. Se non vuoi usare un ORM (perché è solo uno script veloce) ma ti piace la mappatura degli oggetti, è DAVVERO bello:

class Student {

    public $id;
    public $first_name;
    public $last_name

    public function getFullName() {
        return $this->first_name.' '.$this->last_name
    }
}

try 
{
    $dbh = new PDO("mysql:host=$hostname;dbname=school", $username, $password)

    $stmt = $dbh->query("SELECT * FROM students");

    /* MAGIC HAPPENS HERE */

    $stmt->setFetchMode(PDO::FETCH_INTO, new Student);


    foreach($stmt as $student)
    {
        echo $student->getFullName().'<br />';
    } 

    $dbh = null;
}
catch(PDOException $e)
{
    echo $e->getMessage();
}

Spostare un'applicazione da un database a un altro non è molto comune, ma prima o poi potresti trovarti a lavorare su un altro progetto usando un RDBMS diverso. Se sei a casa con la DOP, allora ci sarà almeno una cosa in meno da imparare a quel punto.

A parte questo, trovo l'API PDO un po 'più intuitiva e mi sento più veramente orientata agli oggetti. mysqli si sente come se fosse solo un'API procedurale che è stata oggettificata, se sai cosa intendo. In breve, trovo la DOP più facile da lavorare, ma ovviamente è soggettiva.

Ho iniziato a usare DOP perché il supporto delle dichiarazioni è migliore, secondo me. Sto usando un livello di accesso ai dati di tipo ActiveRecord ed è molto più semplice implementare istruzioni generate dinamicamente. L'associazione dei parametri di MySQLi deve essere eseguita in una singola chiamata di funzione / metodo, quindi se non si conosce fino al runtime quanti parametri si desidera associare, si è costretti a utilizzare call_user_func_array()(credo che sia il nome della funzione corretta) per le selezioni . E dimentica la semplice associazione dinamica dei risultati.

Soprattutto, mi piace la DOP perché è un livello di astrazione molto ragionevole. È facile da usare in sistemi completamente astratti in cui non si desidera scrivere SQL, ma semplifica anche l'uso di un sistema di query più ottimizzato e puro, oppure per combinare i due elementi.

DOP è lo standard, è ciò che la maggior parte degli sviluppatori si aspetta di utilizzare. mysqli era essenzialmente una soluzione su misura per un problema particolare, ma ha tutti i problemi delle altre librerie specifiche del DBMS. DOP è dove tutto il duro lavoro e il pensiero intelligente andranno.

Ecco qualcos'altro da tenere a mente: per ora (PHP 5.2) la libreria PDO è difettosa . È pieno di strani bug. Ad esempio: prima di archiviare a PDOStatementin una variabile, la variabile dovrebbe essere unset()per evitare una tonnellata di bug. La maggior parte di questi sono stati corretti in PHP 5.3 e saranno rilasciati all'inizio del 2009 in PHP 5.3 che probabilmente avrà molti altri bug. Dovresti concentrarti sull'uso di PDO per PHP 6.1 se vuoi una versione stabile e sull'uso di PDO per PHP 5.3 se vuoi aiutare la comunità.

Un'altra notevole (buona) differenza sul DOP è che il suo PDO::quote()metodo aggiunge automaticamente le virgolette allegate, mentre mysqli::real_escape_string()(e simili) no:

PDO :: quote () posiziona le virgolette attorno alla stringa di input (se necessario) e sfugge ai caratteri speciali all'interno della stringa di input, usando uno stile di quotazione appropriato per il driver sottostante.

PDO renderà molto più semplice il ridimensionamento se la tua app Web / del sito diventa realmente reale poiché puoi configurare quotidianamente connessioni Master e slave per distribuire il carico attraverso il database, inoltre PHP si sta dirigendo verso lo spostamento su PDO come standard.

Informazioni DOP

Ridimensionamento di un'applicazione Web

In termini di velocità di esecuzione, MySQLi vince, ma a meno che tu non abbia un buon wrapper che utilizza MySQLi, le sue funzioni che si occupano di istruzioni preparate sono terribili.

Ci sono ancora bug nei miei, ma se qualcuno lo vuole, eccolo qui .

Quindi in breve, se stai cercando un guadagno di velocità, allora MySQLi; se si desidera facilità d'uso, quindi DOP.

Personalmente uso la DOP, ma penso che sia principalmente una questione di preferenza.

PDO ha alcune funzioni che aiutano ancora una volta l'iniezione di SQL ( istruzioni preparate ), ma se stai attento con il tuo SQL puoi farlo anche con mysqli.

Passare a un altro database non è tanto un motivo per usare il DOP. Finché non si utilizzano "funzioni SQL speciali", è possibile passare da un DB a un altro. Tuttavia, non appena si utilizza ad esempio "SELEZIONA ... LIMIT 1" non è possibile accedere a MS-SQL dove si trova "SELEZIONA TOP 1 ...". Quindi questo è problematico comunque.

Risposta modificata.

Dopo aver avuto qualche esperienza con entrambe queste API, direi che ci sono 2 funzionalità di livello di blocco che rendono mysqli inutilizzabile con istruzioni preparate native.
Sono già stati menzionati in 2 risposte eccellenti (eppure sottovalutate):

1. Valori vincolanti al numero arbitrario di segnaposto
2. Restituzione dei dati come un semplice array

(entrambi menzionati anche in questa risposta )

Per qualche motivo mysqli non è riuscito con entrambi.
Oggi ha ottenuto alcuni miglioramenti per il secondo ( get_result ), ma funziona solo su installazioni mysqlnd, il che significa che non puoi fare affidamento su questa funzione nei tuoi script.

Eppure non ha vincoli per valore fino ad oggi.

Quindi, c'è solo una scelta: DOP

Tutti gli altri motivi, come ad esempio

• segnaposto nominati (questo zucchero di sintassi è molto sopravvalutato)
• supporto di database diversi (nessuno l'ha mai effettivamente utilizzato)
• recuperare in oggetto (solo zucchero di sintassi inutile)
• differenza di velocità (nessuna)

non hanno alcuna importanza significativa.

Allo stesso tempo, entrambe queste API mancano di alcune funzionalità davvero importanti , come

• segnaposto identificativo
• segnaposto per i tipi di dati complessi per rendere meno impegnativa l'associazione dinamica
• codice dell'applicazione più breve.

Quindi, per coprire le esigenze della vita reale , è necessario creare la propria libreria di astrazione, basata su una di queste API, implementando segnaposto analizzati manualmente. In questo caso preferirei mysqli, poiché ha un livello di astrazione minore.

Nel mio script di benchmark , ogni metodo viene testato 10000 volte e viene stampata la differenza del tempo totale per ciascun metodo. Dovresti farlo sulla tua configurazione, sono sicuro che i risultati varieranno!

Questi sono i miei risultati:

• " SELECT NULL" -> PGO()più veloce di ~ 0,35 secondi
• " SHOW TABLE STATUS" -> mysqli()più veloce di ~ 2.3 secondi
• " SELECT * FROM users" -> mysqli()più veloce di ~ 33 secondi

Nota: usando -> fetch_row () per mysqli, i nomi delle colonne non vengono aggiunti all'array, non ho trovato un modo per farlo in PGO. Ma anche se uso -> fetch_array (), mysqli è leggermente più lento ma comunque più veloce di PGO (tranne SELECT NULL).

Una cosa che PDO afferma che MySQLi non mi piace davvero è la capacità del PDO di restituire un risultato come oggetto di un tipo di classe specificato (ad es $pdo->fetchObject('MyClass').). MySQLi fetch_object()restituirà solo un stdClassoggetto.

C'è una cosa da tenere a mente.

Mysqli non supporta la funzione fetch_assoc () che restituirebbe le colonne con le chiavi che rappresentano i nomi delle colonne. Naturalmente è possibile scrivere la propria funzione per farlo, non è nemmeno molto lungo, ma ho avuto davvero difficoltà a scriverla (per i non credenti: se ti sembra facile, provalo da solo e non t imbrogliare :))