Newsgroup: it.comp.software.database
Titolo: join or not join... this is the problem

Salve,
analizzando il codice di un noto script open source che utilizza PHP/MySQL
ho notato che in una certa situazione viene evitato l'utilizzo di JOIN SQL.
Supponiamo, semplificando tutto il discorso, di avere due tabelle MySQL
in relazione tra loro, con "user_rank" che è chiave esterna rispetto a 
"rank_id":
user
- user_id
- user_name
- user_rank
rank
- rank_id
- rank_desc
Supponiamo ora di dover mostrare l'elenco degli utenti con l'indicazione del 
rank
cui ognuno di essi appartiene, considerando che nella tabella user sono 
presenti
numerosi record mentre nella tabella rank sono presenti poche decine di 
record.
Quello che mi chiedo è quale approccio SQL sia mediamente il più efficiente 
tra:
a) Una query con left join tra le tabelle user e rank
b) Due query singole rispettivamente su rank e su user per poi mappare da 
PHP user_rank con rank_desc
Soluzione A
SQL: SELECT user_name, rank_desc FROM user LEFT JOIN rank ON 
user_rank=rank_id LIMIT ...
Soluzione B
SQL: SELECT rank_id, rank_desc FROM rank
SQL: SELECT user_name, user_rank FROM user LIMIT ...
PHP: Mappatura tra user_rank ed il corrispondente rank_desc
Ovviamente, la valutazione di soluzione più efficiente la intendo in termini 
SQL,
dunque escludendo qualsiasi ulteriore considerazione riguardante la 
mappatura
che nel caso B dovrà poi effettuare il PHP.
Attendo impazientemene i vostri pareri.
Grazie,
Riccardo
-- 
* Immolo - Portale immobiliare
* 
http://www.immolo.it

 effettuare il PHP.
La soluzione B e` quella che consuma meno risorse lato server; la
soluzione A e` la piu` ragionevole.
Quella consigliabile e` la soluzione A per praticita`, specialmente
considerando che il risparmio con la B e` molto basso nel tuo caso
(tabella di lookup con poche righe).
Esattamente quale problema vuoi risolvere? Non vorrei fosse un caso
di premature optimization. 

 ha scritto nel messaggio 
news:%btNj.291098$%k.40...@twister2.libero.it...

Ho un sito di annunci immobiliari e vorrei ottimizzare/minimizzare il carico
di lavoro del server MySQL.
Sto lavorando a 360° per ottimizzare struttura del DB e query.
Grosso modo ho una tabella principale di annunci (anche se in verità
la tabella annunci è spezzata in due sotto-tabelle per motivi di efficienza)
che contiene circa 750000 record e delle tabelle secondarie:
reparti: 2 record
gruppi: 2 record
categorie: 36 record
regioni: 20 record
provincie: 107 record
comuni: 8101 record
Le tabelle secondarie sono fondamentalmente tutte costituite da un codice
oppure da un ID e da un nome/descrizione.
Le query eseguite più frequentemente riguardano la selezione di annunci
completi delle informazioni descrittive delle varie sottotabelle.
L'esempio completo e dunque non troppo semplificato della domanda
che mi pongo è... cosa sia meglio fare RIPETUTAMENTE tra:
A) Una query con 6 left join tra le tabelle annunci e le 6 tabelle 
secondarie
B) Una query senza left join sugli annunci e 6 query singole sulle tabelle 
secondarie per poi mappare i valori descrittivi tra annunci e tabelle 
secondarie direttamente da PHP
Tieni presente anche che la query sugli annunci ha dei LIMIT impostati.
P.S.
Mi chiedo anche se ho fatto veramente bene a suddividere la tabella annunci 
in due sottotabelle (annunci_base, annunci_text)
per far si che la prima tabella maggiormente utilizzata per selezionare i 
record abbia un tipo di record di tipo "fisso" ed una lunghezza
più ridotta per aumentare le prestazioni di ricerca e ordinamento 
specialmente nel caso di utilizzo di tabelle temporanee da parte di mysql
per eseguire le query richieste... ma questo è tutto un altro discorso, 
magari ne parliamo un'altra volta.
Ciao,


 una lunghezza più ridotta
L'idea dei record a larghezza fissa e` giusta, ma questo e` (ri)fare
a mano quello che invece dovrebbe fare il dbms.
Non conosco MySql, ma e` probabile che il motore lo stia gia` facendo
a livello fisico; (ossia mette un puntatore al posto di una stringa
di tipo varchar o text).
Un altro svantaggio e` che precludi ulteriori ottimizzazioni, dato
che il codice si "fonde" con questa ottimizzazione.
bye 

 bye
Grazie per la risposta,


 te lo dico per certo
Peccato, quanto lavoro si sarebbe risparmiato... 

 comuni: 8101 record
Una soluzione potrebbe essere quella di sostituire reparti, gruppi e 
regioni in array, anzichè tabelle.
Sicuramente regioni, visto che dubito in un mutamento dei contenuti.
Cosi' non devi fare un bel po' di join, no?
Se le popoli in un include, ti basta allegarlo ai programmi che ne fanno 
  uso.
my 2 cent
Lucignolo
-- 
Sign in progress