Fare calcoli in MySQL vs PHP

Giocherei sui punti di forza di ogni sistema.

La logica di aggregazione, unione e filtraggio appartiene ovviamente al livello dati. È più veloce, non solo perché la maggior parte dei motori DB ha oltre 10 anni di ottimizzazione per fare proprio questo, ma riduci al minimo i dati spostati tra il tuo DB e il server web.

D'altra parte, la maggior parte delle piattaforme DB che ho usato hanno funzionalità molto scarse per lavorare con i valori individuali. Cose come la formattazione della data e la manipolazione delle stringhe fanno solo schifo in SQL, è meglio farlo in PHP.

Fondamentalmente, usa ciascun sistema per ciò per cui è stato creato.

In termini di manutenibilità, fintanto che la divisione tra ciò che accade dove è chiara, separarli in tipi di logica non dovrebbe causare molti problemi e certamente non abbastanza per eliminarne i vantaggi. A mio avviso, la chiarezza e la manutenibilità del codice riguardano più la coerenza che il mettere tutta la logica in un unico posto.

Re:esempi specifici...

1. So che non è quello che ti riferisci anche tu, ma le date sono quasi un caso speciale. Si desidera assicurarsi che tutte le date generate dal sistema vengano create sul server Web OPPURE sul database. In caso contrario, si verificheranno alcuni bug insidiosi se il server db e il server web sono mai configurati per fusi orari diversi (l'ho visto accadere). Immagina, ad esempio, di avere un createdDate colonna con un valore predefinito di getDate() che viene applicato sull'inserto dal DB . Se dovessi inserire un record, allora, utilizzando una data generata in PHP (ad es. date("Y-m-d", time() - 3600) , seleziona i record creati nell'ultima ora, potresti non ottenere ciò che ti aspetti. Per quanto riguarda il livello su cui dovresti farlo, preferirei il DB perché, come nell'esempio, ti consente di utilizzare i valori predefiniti delle colonne.

2. Per la maggior parte delle app lo farei in PHP. Combinare nome e cognome sembra semplice fino a quando non ti rendi conto che a volte hai bisogno anche di saluti, titoli e iniziali centrali. Inoltre, finirai quasi sicuramente in una situazione in cui desideri un nome utente, un cognome E una combinazione di saluto + nome + cognome. Concatenarli lato DB significa che si finisce per spostare più dati, anche se in realtà è piuttosto minore.

3. Dipende. Come sopra, se vuoi usarli separatamente, è meglio in termini di prestazioni estrarli separatamente e concatenarli quando necessario. Detto questo, a meno che i set di dati con cui hai a che fare non siano enormi, probabilmente ci sono altri fattori (come, come dici tu, la manutenibilità) che hanno più rilevanza.

Alcune regole pratiche:

• La generazione di ID incrementali dovrebbe avvenire nel DB.
• Personalmente, mi piace il mio valore predefinito applicato dal DB.
• Quando si seleziona, qualsiasi cosa che riduca il numero di record dovrebbe essere eseguita dal DB.
• Di solito è utile fare cose che riducano le dimensioni del lato DB del set di dati (come con l'esempio delle stringhe sopra).
• E come dici tu; l'ordinamento, l'aggregazione, le sottoquery, i join, ecc. devono sempre essere lato DB.
• Inoltre, non ne abbiamo parlato, ma di solito i trigger sono negativi/necessari.

Ci sono alcuni compromessi fondamentali che devi affrontare qui e il saldo dipende davvero dalla tua applicazione.

Alcune cose dovrebbero assolutamente essere sempre eseguite in SQL. Escludendo alcune eccezioni (come le date) per molte attività, SQL può essere molto goffo e può lasciarti con la logica in luoghi fuori mano. Quando cerchi nella tua codebase i riferimenti a una colonna specifica (ad esempio), lo è facile perdere quelli contenuti in una vista o in una procedura memorizzata.

Le prestazioni sono sempre una considerazione ma, a seconda dell'app e dell'esempio specifico, forse non è importante. Le tue preoccupazioni sulla manutenibilità sono probabilmente molto valide e alcuni dei vantaggi in termini di prestazioni che ho menzionato sono molto lievi, quindi fai attenzione all'ottimizzazione prematura.

Inoltre, se altri sistemi accedono direttamente al DB (ad es. per la creazione di report o import/export) trarrai vantaggio dall'avere più logica nel DB. Ad esempio, se desideri importare direttamente utenti da un'altra origine dati, in SQL viene implementata una funzione di convalida e-mail riutilizzabile.

Risposta breve:dipende. :)