Visualizzazione dei risultati da 1 a 5 su 5
  1. #1

    MYSQL e PHP a confronto

    Ciao a tutti!
    Ho sempre avuto questo dubbio atroce in testa, e ho proprio voglia di togliermelo.

    Se si deve fare una operazione sui dati, conviene farla in MYSQL o in PHP?

    Ad esempio, voglio prendere tutti i dati di una tabella T, e poi calcolare la somma della colonna X con X contenuto in T.
    Faccio due query: una che prende i dati, e una che calcola la somma.
    Oppure prendo tutti i dati (una sola query) e poi con un algoritmo srotolo la matrice di dati e mi calcolo tramite php la somma della colonna da me desiderata: in parole povere, SUM del MYSQL riprodotto tramite PHP.


    Quanto è costoso fare una Query?... ad esempio se ho 10000 utenti sul mio server, come faccio a sapere se il numero di query che sto creando è troppo elevato o meno.
    Praticamente voglio avere delle conoscenze tali che nella fase di progettazione mi posso rendere conto se il numero di query per utente è spropositato e decidere in tal caso di cambiare sistema.

    ps: Sarei felicissimo se nella risposta mi consigliasse anche qualche libro/articolo da leggermi su questo argomento che ho citato. Credo sia un argomento complesso che non mi può essere spiegato facilmente :P.


    Grazie

  2. #2
    In realtà per la somma in SQL basterebbe una query:

    codice:
    SELECT ( X + Y ) AS totale FROM Table
    Secondo me, per operazioni semplici (che puoi fare con gli operatori e le funzioni SQL) non credo ci sia grande differenza.

    Secondo me quello che costa di più a livello computazionale, è il numero di connessioni al database: dovresti ottimizzare per farne il meno possibile.


  3. #3
    direi (ovviamente) mysql

    nel caso in cui non sia possibile usare una sola query (sia perché sarebbe TROPPO complessa o sia perché a causa magari dell'elevato numero di join e non è possibile usare efficentemente i raggruppamenti facendo tirare fuori troppa roba inutile) solitamente le spezzo tipo in 2 query:
    - con la prima acquisisco i dati e mi segno i valori delle chiavi primarie dei record acquisiti
    - con la seconda estraggo i dati ulteriori che mi servono passando nel WHERE tramite la keyword IN l'elenco delle chiavi primarie su cui lavorare

    Così facendo si evitano oscenità (tipo una query lanciata per ogni record estratto o cose del genere)

    In generale considera che MySQL è più veloce, nella maggioranza delle volte, ad eseguire le operazioni per il semplice motivo che se stai lavorando su 1000 records (ad es) lui interpreta 1 sola volta la query e poi esegue l'operazione mentre con php (benché il codice viene compilato in bytecode) deve eseguire il ciclo 1000 ... una cosa è se lo fa il C/C++ una cosa è se lo fa il motore zend interpretando il bytecode del codice php ^^
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  4. #4
    grazie delle risposte... ma mi piacerebbe saperne di piú sull'argomento.
    Non conoscete qualche articolo o libro che parla dell'argomento?

  5. #5
    Caccio ho ancora problemi... dovrei proprio leggermi un libro sull'argomento, altrimenti mi vengono dubbi ogni secondo.
    Nessuno ne sa proprio niente riguardo a libri che potrei leggere sull'argomento?


    Cmq vorrei capire.
    è meglio fare x query oppure un uniaca query unendo i risultati con UNION?

    Soprattuto viene applicata qualche ottimizzazione durante l'unione di due tabelle?
    Ad esempio se io velessi fare due query così:
    1) SELECT attA,attB,attrC FROM A JOIN B JOIN C
    2) SELECT attA,attB,attrD FROM A JOIN B JOIN D

    Si possono unire queste due query in questo modo:
    (SELECT attA,attB,attrC, NULL as attrD FROM A JOIN B JOIN C)
    UNION
    (SELECT attA,attB,NULL as attrC, attrD FROM A JOIN B JOIN D)


    Ma quali vantaggi si hanno?
    Cmq l'SQL dovrà ricalolarsi da zero la giunzione tra A e B... oppure viene salvata in memoria e quindi si ottimizza automaticamente questa query.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2026 vBulletin Solutions, Inc. All rights reserved.