Pulizia della struttura OO rispetto alle prestazioni SQL

Question

Quando si programma in PHP, cerco sempre di creare "modelli" (classi) significativi che corrispondono alle tabelle nel database. Incontro spesso il seguente problema:

Supponendo di aver creato un database con due tabelle: authors e blogs, che hanno entrambi un modello corrispondente nella mia applicazione.

Diciamo che voglio stampare tutti i blog con informazioni sull'autore, avrei dovuto fare qualcosa di simile:

<?php 
foreach ($app->getBlogs() as $blog) { 
    echo "<h1>" . $blog->title . "</h1>"; 
    echo "Written by" . $blog->getAuthor()->name . "</p>"; 
    // ... et cetera 
} 
?> 

Il problema è che l'applicazione sarà ora il fuoco 1 query SQL ottenere tutti gli articoli del blog e [numero di articoli del blog] query per ottenere le informazioni per ogni autore. Avendo SQL semplice usato avrei potuto recuperare queste informazioni utilizzando una semplice query:

SELECT * FROM blogs 
JOIN authors ON authors.id = blogs.author 

Qual è il modo migliore di affrontare tali questioni: lo sviluppo di un'applicazione orientata agli oggetti senza eseguire troppe query SQL inutili.

Answer 1

IMO, penso che dovresti scrivere solo un'altra classe che incapsulerà quello che hai. Ha sempre senso che un blog abbia un autore? Ogni autore ha un blog? Un autore può avere più blog? Pensa a questi problemi, quindi progetta una classe che incapsulerà questo. Ricorda, i tipici schemi di database non sono OO ... sono relazionali. Sì, sono vicini, ma ci sono sottili differenze.

Quindi, se un autore può avere più blog, è possibile avere una chiave per una classe multivalore di qualche tipo (con la chiave basata sull'ID autore) e si può inizializzare o caricare questa classe con una chiamata SQL. Solo alcune cose a cui pensare.

Answer 2

Qualunque soluzione tu usi, ORM o no, dovrebbe essere in grado di emettere una singola selezione in questo caso, e dovrebbe anche essere in grado di selezionare solo le colonne necessarie. Quindi da quel join dovrebbe essere in grado di popolare gli oggetti autori con corrispondenti elenchi di blog per autore. Dover pubblicare più SQL è uno spreco.

Answer 3

Questo è il classico problema di ORM. Molte molte scuole di pensiero. Non sono sicuro delle specifiche del php, ma ci sono diverse strategie per risolvere questa "mancata corrispondenza dell'impedenza". Google orm.

Answer 4

Cose come questa sono esattamente ciò che la creazione del proprio livello di dati dovrebbe risolvere per voi. Nel tuo modello per i tuoi blog, dovrebbe esserci una funzione come getBlogList() che restituirà i titoli del blog e il nome dell'autore in un'unica query.

Answer 5

un modo per fare ciò è creare una vista con il join in esso e visualizzare i risultati della visualizzazione in un'altra classe che contiene dati per blog e autore.

Answer 6

Propel è un esempio di un ORM PHP che può far fronte a questo. Sono sicuro che Doctrine deve essere in grado di farlo, anche se non l'ho mai guardato.

Perché reinventare la ruota?

Answer 7

A meno che non si sappia che le inefficienti operazioni di SQL non avranno alcun impatto reale, come il numero di iterazioni ridondanti o le righe interessate sarà sempre piccola (ad esempio, iterando un'operazione sul numero di figli di una famiglia, che, a meno di rarissimi casi come i Duggars, si può contare su meno di 10), ho sempre privilegiato l'efficienza della query relazionale sulla bellezza del codice OO.

Sebbene il brutto codice OO possa rendere la manutenzione un problema, l'accesso inefficiente ai dati può mettere in ginocchio un sistema, di solito quando si è in vacanza o si cerca di dormire. E la maggior parte delle volte, è possibile trovare un buon compromesso che rende le operazioni SQL più efficienti con un'interfaccia ragionevolmente "obiettiva". Potrebbe costare un po 'più tempo quando si tratta di rifattorizzare o aggiungere funzionalità se il tuo modello di oggetto non è bello, ma sta costando tempo ai tuoi clienti ogni volta che spingono quel pulsante (o denaro in termini di hardware più grande per eseguire il app - mai un buon metodo di ottimizzazione), e le ore di lavoro trascorse con l'app dovrebbero superare di gran lunga le ore lavorative impiegate per svilupparlo (ci si aspetterebbe).

Per quanto riguarda la necessità di un'interfaccia (costringendovi a capire tutti i possibili modelli di consumo), ho affrontato questo problema eseguendo tutte le mie modifiche dei dati tramite stored procedure, ma consentendo l'accesso ai dati direttamente. contro le tabelle & visualizzazioni dando a tutti gli utenti solo i privilegi di selezione. Questa è una posizione semi-controverso, poiché molte persone vorrebbero bloccare tutte le operazioni di accesso ai dati da parte dei consumatori a valle nel nome di garantire che tutti gli sql eseguiti siano conformi ai loro standard. Ma i nuovi modi di guardare i dati sono sempre in arrivo, e se devi aggiungere un nuovo stored proc, aggiornare le tue librerie di classi core e aggiornare il codice cliente ogni volta che qualcuno vuole implementare una nuova funzionalità, la distribuzione e la qualifica possono crescere essere un peso reale - molto più che dover affrontare un modello di oggetto che non si adatta ad un ideale religioso. Ed è molto più semplice implementare un processo di ispezione del codice che verifichi che le nuove dichiarazioni selezionate scritte dai consumatori a valle siano kosher.

Answer 8

Onestamente, basta creare un metodo sul tuo blog classe chiamata getBlogsWithAuthors() e quindi eseguire

SELECT * 
FROM blogs 
JOIN authors 
     ON authors.id = blogs.author 

So che può sembrare come un dolore di scrivere cose come questa per ogni classe del modello, ma non c'è davvero nessun altro modo. Si potrebbe fare un po 'più dinamica, però:

//this is a method of a model class. 
//Assume $this->table is the table name of the model (ie, Blog) 
public function getWith($joinTable, $pivot1, $pivot2) 
{ 
    $sql="SELECT * 
      FROM {$this->table} 
      JOIN $joinTable 
        ON $pivot1 = $pivot2"; 

    return executeQuery($sql);  
} 

$blog=new Blog(); 
$result=$blog->getWith('authors', 'authors.id', 'blogs.author'); 
[play with results here] 

Answer 9

Sono un grande sostenitore ORM, e qui è il mio peso-in:

Va bene per il commercio una quantità inperceptible delle prestazioni delle applicazioni per una tonnellata delle prestazioni dello sviluppatore. I server sono estremamente potenti in questi giorni e quel ferro extra ci dà una nuova flessibilità.

Detto questo, se fai qualcosa di stupido che annienta l'esperienza dell'utente mettendo in ginocchio il server, non va più bene. Se avessi un milione di autori nel tuo esempio, trascinarli tutti insieme a tutti i loro campi e scorrere le righe sarebbe imprudente. Se avessi solo 20 autori, non è un grosso problema.

Nel caso di enormi set di dati e costose operazioni batch, anche come un ORM, devo ottimizzare e scrivere sprocs speciali o istruzioni SQL solo per quel caso. E devo stare attento a non scrivere il mio codice in modo tale che io martello il database sarebbe meglio usare un modello di cache in cui estraggo un grande set di dati e poi lavoro fuori da quello.

Questo è un grande dibattito in corso, ma per me è solo una questione di capire che non è possibile risolvere ogni problema con un singolo strumento.

Answer 10

Ho usato alcuni altri attacchi .. Esempio:

<?php 
$blogs = $app->getBlogs(); 
$blogs->getAuthor(); 
foreach ($blogs as $blog) { 
    echo "<h1>" . $blog->title . "</h1>"; 
    echo "Written by" . $blog->getAuthor()->name . "</p>"; 
    // ... et cetera 
} 
?> 

-> getAuthor() chiamata sul blog $ interroga il DB solo una volta, e l'utilizzo di oggetto speciale per array, la chiamata getAuthor() viene chiamato su ciascuno (ma, in qualche modo è ottimizzato per essere eseguito solo come una query).

Answer 11

È sempre possibile utilizzare memcached come livello intermedio. Ogni query dovrebbe essere basata esclusivamente sulla RAM, il che significa che puoi eseguire quanti ne vuoi.

Answer 12

Hai già risposto alla domanda:

aver usato SQL semplice avrei potuto recuperare queste informazioni utilizzando una query semplice

Avete una scelta tra SQL che recupera solo blog post e SQL che recupera i post del blog e autori. Allo stesso modo si ha una scelta tra un codice PHP che recupera solo post di blog o codice PHP che recupera i post del blog e gli autori. Devi fare una scelta sul tuo codice PHP, così come devi fare una scelta sul tuo SQL.

Ci sono molti esempi sopra che dimostrano come ciò funzionerebbe nella pratica. Anche la raccomandazione di usare Doctrine o Propel è buona.

Answer 13

Considera la separazione di comando/query come descritto da Greg Young e Martin Fowler. Il tuo modello di query può avere Blog e autore de-normalizzati in una singola tabella ottimizzata per il recupero di DTO per il tuo livello di presentazione.

Greg Young ha un'ottima presentazione su CQS su InfoQ.