Quando è meglio scaricare il lavoro su RDBMS piuttosto che farlo in codice?

12

Ok, mi occuperò di questo: sono un programmatore migliore di quello che trovo nei database, e mi chiedo dove le considerazioni sulle "migliori pratiche" si trovano sull'argomento di fare calcoli "semplici" nella query SQL vs nel codice, come questo esempio di MySQL (non l'ho scritto, devo solo mantenerlo!) - Questo restituisce il nome utente, e gli utenti invecchiano a partire dall'ultimo evento.

SELECT u.username as user, 
       IF ((DAY(max(e.date)) - DAY(u.DOB)) < 0 ,   
       TRUNCATE(((((YEAR(max(e.date))*12)+MONTH(max(e.date)))
       -((YEAR(u.DOB)*12)+MONTH(u.DOB)))-1)/12, 0),  
       TRUNCATE((((YEAR(max(e.date))*12)+MONTH(max(e.date))) -            
       ((YEAR(u.DOB)*12)+MONTH(u.DOB)))/12, 0)) AS age   
FROM users as u
JOIN events as e ON u.id = e.uid
...

Rispetto al sollevamento "pesante" nel codice:

Query:

SELECT u.username, u.DOB as dob, e.event_date as edate
FROM users as u
JOIN events as e ON u.id = e.uid

code:

function ageAsOfDate($birth, $aod)
{    //expects dates in mysql Y-m-d format...
     list($by,$bm,$bd) = explode('-',$birth);
     list($ay,$am,$ad) = explode('-',$aod);

     //Insert Calculations here 
     ...
     return $Dy; //Difference in years
}

echo "Hey! ". $row['user'] ." was ". ageAsOfDate($row['dob'], $row['edate']) . " when we last saw him."; 

Sono abbastanza sicuro che in un caso semplice come questo non farebbe molta differenza (a parte il sentimento strisciante di orrore quando devo apportare modifiche a domande come la prima), ma penso che sia più chiaro quello che sto cercando.

Grazie!

    
posta GeminiDomino 16.11.2010 - 17:57
fonte

5 risposte

13

Si desidera eseguire tutte le operazioni basate su set nel database per motivi di prestazioni. Quindi funzioni di aggregazione, funzioni di ordinamento, join ecc.

Questo calcolo dell'età, lo farei in codice. L'unica ragione per cui potrei mai fare qualcosa di simile in una query di database è se richiedesse un sacco di colonne che altrimenti non selezionerei che potrebbero effettivamente ammontare a un numero sufficiente di dati per rallentare significativamente la mia query. La selezione di alcuni valori interi non comporterà una significativa differenza di prestazioni. E anche se fa una moderata differenza di prestazioni, sarò spinto a mantenere questa logica nel codice dell'applicazione.

    
risposta data 16.11.2010 - 18:24
fonte
4

Ogni caso è diverso

È la logica ...

  • necessari ad altri clienti? ASCIUTTO: nel database
  • utilizzato per ulteriori elaborazioni? es. ordina per età decrescente: nel database
  • richiede impostazioni regionali? gg / mm / aaaa o mm / gg / aaaa: nel client
  • usato spesso? Perché calcolarlo ancora e ancora: usa la colonna calcolata e persistente nel database

Nel caso questo , potrei usare una colonna calcolata e persistente nel database

Potrebbe essere peggio: si potrebbe avere questo nel database:

"Hey! ". u.username." was ". <datecalc>. " when we last saw him."
    
risposta data 16.11.2010 - 18:49
fonte
3

Fondamentalmente dovresti considerare due cose: l'utilizzo della CPU e il traffico di rete. Non dovresti generare risposte enormi, trasferirle sulla rete e riassumerle nel frontend, poiché il database può fare molto meglio.

Per i dati manipolazione è un trade-of. Se il database spende quantità equivalenti di cicli di CPU sul tuo codice di frontend facendo la stessa cosa - dato che la quantità di dati trasferiti è approssimativamente equivalente), allora non importa dove. Allora fallo dove hai la più grande esperienza di programmazione. Spesso, puoi ottenere un lungo cammino con una selezione attenta e che potrebbe essere molto utile.

    
risposta data 16.11.2010 - 18:43
fonte
1

Ne hai menzionato uno: area di competenza. Forse la struttura del database non è troppo intensiva, quindi decidi di scaricare parte dello sviluppo della logica in un membro del team che è più centrato sul database. Potrebbe non essere l'ideale, ma se sei a corto di tempo ...

L'hardware del database ha molte più risorse di altri server e non è possibile modificarlo. Questo potrebbe non essere applicabile a questa situazione specifica, ma potrebbe essere necessario prendere in considerazione.

Ci sono altre applicazioni che potrebbero richiedere la logica al di fuori del tuo codice. Alcuni strumenti di scrittura di report potrebbero non essere in grado di utilizzare un servizio Web o un'API. Potresti duplicare la logica o se ritieni che i requisiti possano divergere.

    
risposta data 16.11.2010 - 18:27
fonte
0

Ho sempre sbagliato a dedicare tutta l'elaborazione al DB. La tua sintassi sopra potrebbe anche essere scritta con funzioni DB che sarebbero IMO una soluzione molto pulita.

    
risposta data 28.12.2010 - 20:09
fonte

Leggi altre domande sui tag