Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 14
  1. #1

    10 left join in una query o 10 query?

    vorrei sapere, a livello di carico per il database e di rallentamenti, è meglio effettuare 10 left join (per ricercare i valori all'interno di 10 tabelle diverse) oppure 10 query (una per ogni tabella)?

    perchè mi è come sembrato che le 10 left join vadano più lente di 10 query..però probabile che mi sbagli

    grazie per le risposte
    Uala, CTO
    Tom's Hardware
    , full stack developer
    Gamempire.it, director

  2. #2
    Teoricamente è più veloce con le 10 query.

    Operando una join (che sia left o no penso non influsica) per ogni record della prima tabella scorre tutti i record della seconda.

    Ti conseguenza se metti in catena 10 tabelle potresti ben immaginare i voli pindarici che si fa

    Se invece fai 10 query separate per ogni "singola" tabella risparmi una valanga di giri e di conseguenza è sicuramente più veloce

  3. #3
    Originariamente inviato da Debiru
    Teoricamente è più veloce con le 10 query.

    Operando una join (che sia left o no penso non influsica) per ogni record della prima tabella scorre tutti i record della seconda.

    Ti conseguenza se metti in catena 10 tabelle potresti ben immaginare i voli pindarici che si fa

    Se invece fai 10 query separate per ogni "singola" tabella risparmi una valanga di giri e di conseguenza è sicuramente più veloce

    Sicuramente hai anche meno rompicapi , immagina la complessità della query con 10 left join...
    Realizzazione Software, Siti Web ed E-commerce. Consulenza Software ed esperti open source ...
    Scopri i nostri servizi...

  4. #4
    la complessità non mi preoccupa..sono le risorse chieste al server che invece mi preoccupano

    questa è la join:

    codice:
    $query="
    		SELECT rr.*, tt.*, ss.*, aa.*, dd.*, sh.*, ii.*, cc.*, al.*, vv.* 
    		FROM games gg 
    		LEFT JOIN recensione rr ON gg.id = rr.id_game 
    		LEFT JOIN trucchi tt ON gg.id = tt.id_game 
    		LEFT JOIN soluzione ss ON gg.id = ss.id_game 
    		LEFT JOIN anteprima aa ON gg.id = aa.id_game 
    		LEFT JOIN download dd ON gg.id = dd.id_game 
    		LEFT JOIN scheda sh ON gg.id = sh.id_game 
    		LEFT JOIN immagini ii ON gg.id = ii.id_game 
    		LEFT JOIN cover cc ON gg.id = cc.id_game 
    		LEFT JOIN altridati al ON gg.id = al.id_game 
    		LEFT JOIN voti vv ON gg.id = vv.id_game 
    		WHERE gg.id = '".$id."'
    	";
    Uala, CTO
    Tom's Hardware
    , full stack developer
    Gamempire.it, director

  5. #5
    Bhè, indubbiamente sarebbe molto meglio una query alla volta, però non posso non notare che la struttura del db è un pò troppo espansa.

    Ovvero, ci sono ben 10 tabelle che si riferiscono in primo luogo ad un'unica tabella, sarebbe stato meglio, secondo me, raggruppare tutte e 10 le tabelle in un'unica tabella di servizio.

    Es.

    Struttura attuale:

    Tab game -> 10 tabelle diverse.

    Ipotetica struttura:

    Tab game -> 1 tab generica -> 1 tab tipo

    Fai conto in generica metti un campo indice, uno testo lungo e uno indice esterno verso tipo.

    Se in testo ci metti la recensione allora l'indice di tipo sarà 1, se ci metti un trucco allora sarà 2, e così via...

    Non ne risulta una struttura più snella e funzionale?

  6. #6
    priam era così..prima c'era solo la tabella games..poi ho diviso il tutto, xke devi far conto che ogni tabella (recensioni, soluzioni, trucchi ecc), ha allinterno il campo data_recensione, autore_recensione e recensione..questo per ogni articolo..
    quindi fare un operazione simile solo in una tabella vuol dire ke la tabella games dovrebbe contenere na cosa come 40 colonne, per non parlare poi del fatto che ogni gioco avrebbe la maggior parte dei campi vuoti..invece con 10 tabelle non esistonocmbi vuoti e la ricerca è ottimizzata
    Uala, CTO
    Tom's Hardware
    , full stack developer
    Gamempire.it, director

  7. #7
    si poteva benissimo aggiungere una tabella per i metadati che avrebbe contenuto eventuali dati aggiuntivi in forma verticale e non orizzontale

    PS: io sono per le JOIN perché più o meno fa lo stesso lavoro alla fine con la differenza che eviti 10 comandi per le query che vogliono dire tanta roba
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  8. #8
    Tabella Games contiene i dati spedifici unici del gioco

    Tabella Generica contiene Tot campi che possono essere di testo, data, numerici, memo, etc che può essere usata nelle maniere più disparate, conterrà quindi anche l'indice di un gioco e di un Tipo.

    Tabella Tipi che conterrà magari la sola descrizione del Tipo, ma volendo potresti anche omettere la tabella Tipi se ti serve solo per le descrizioni ed affidarti ad un config di fondo.

    Se devi inserire un recensione usi i campi che ti servono di Generica, se devi inserire il Voto usi altri campi.

    In questo modo la struttura tipo sarebbe:

    1 Gioco + N Campi di tipo diverso o uguale su Generica.

    Quì in azienda c'è un mega DB che ha due tabelle che fungono in questo modo e ti posso assicurare che dentro c'è il mondo, ma a seconda di come le prendi possono contenere dati assolutamente eterogenei fra loro.

  9. #9
    giusto per curiosità ... perché sono tutte left join?
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  10. #10
    perchè se uso join normali, potrebbe essere che ci sono dei valori che tipo in soluzioni ci sono ma in trucchi no..e quindi siccome non trova il corrispondente in una tabella, allora non estrae nulla..
    penso quindi che bisogni usare le left join..o sbaglio?
    Uala, CTO
    Tom's Hardware
    , full stack developer
    Gamempire.it, director

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 © 2025 vBulletin Solutions, Inc. All rights reserved.