eheheh, ok...per ora vedo di fare tutto in sottocartelle e mantenere l'algoritmo che ho ora (scorre le sottocartelle senza elenco), poi vedo un po come va.

Come ti sembra il mio sito? E' molto lento? Cosa in particolare?

Giusto per avere un confronto...

Grazie ancora
CIAO!

hai una home da 200 kb,anche questo influisce nel caricamento e visualizzazione della pagina.

guarda se riesci ad elminare qualcosa.

a me dice 22 KB

sicuro sia 200?

Prova a dare un occhio di come ti sembra ora il sito...ho fatto quella modifica delle sottocartelle...ora dovrebbe cercare tra al massimo una 20ina di foto..

il test è semplice.
vuota la cartella dei file temporanei.
carica la pagina e guarda tutto quello che ti tira giù.

per la precisione sono 197 kb

hai ragione

come ti sembra ora la velocità?

ora mi sembra decisamente più veloce.
vado a sensazione, niente dati precisi, però.... ora va molto meglio

bene bene

hai qualche suggerimento per togliere i join che sono FONDAMENTALI per me?

a quali join ti riferisci?

inner join che ci sono in alcune query.

Non parlo di soluzioni "specifiche" ma di un qualcosa di generale per superare dei join

Grazie mille!

non sono i join a creare problemi ma gli indici che hai creato sulle tabelle e la tipologia di indice.

purtroppo conosco poco mssql ed ancora meno mysql ma mi sono ripromesso di prendermi un bel manuale di mysql e studiarlo a fondo per ottimizzare il suo utilizzo.

le regole per ottimizzare un db prevedono la recola ACID innanzitutto,
l'assoluta certezza che il dato è unico nel database e qundi non ridondante,
le tabelle di produzione sono snelle e leggere e quindi ogni dato che non serve più viene storicizzato, gli indici vengono fatti in modo corretto, quelli cluster soprattutto.

se hai ricerche su un po' di testo usa gli indici full text.

qunado fai una query chiedi sempre i dati indispensabili e non fare mai select * from tabella a meno che non sia strettamente indispensabile.

la chiave primaria della tabella dovrà essere un int perchè gestire 4 byte è ben diverso da gestirne n di un varchar.

meglio usare i char perchè mantengono la pagine dei dati contigue mentre con i varchar (più comodi in programmazione) non garantiscono questo e quindi il dato è frammentato.

se fai spesso inserimenti di una certa entità fai in modo di ricostruire gli indici.

@Tymba said:

le tabelle di produzione sono snelle e leggere e quindi ogni dato che non serve più viene storicizzato, gli indici vengono fatti in modo corretto, quelli cluster soprattutto.

qunado fai una query chiedi sempre i dati indispensabili e non fare mai select * from tabella a meno che non sia strettamente indispensabile.

la chiave primaria della tabella dovrà essere un int perchè gestire 4 byte è ben diverso da gestirne n di un varchar.

Allora, diciamo che praticamente faccio già tutto quello che mi consigli.

Unica cosa...non so cosa sono gli indici cluster..

Grazie millissime!

gli indici cluster o meglio l'indice cluster di una tabella è quell'indice che ordina fisicamente sul disco i dati. In sostanza dice con quale ordine andare a scrivere i dati sul disco e quindi eprmette una velocità di interrogazione decisamente superiore.
Non sono sicurissimo che questa tipologia di indice ci sia anche mysql. Ho appena scaricato il manualetto for dummy dal sito (800 pagine porga paletta) ed ora gli do una guardata poi ti faccio sapere qualcosa.

gli indici ce li ha...sono questi cluster che non mi tornano

Grazie mille

CIAO!

si si lo so che gl'indici ci sono ... e ci mancherebbe hehehe
ho il dubbio sull'esistenza degl'indici cluster.

solo a livello di "discussione tra amici" hai mai dato un'occhiata ai benchmark sul sito di mysql?

è un motore veramente con i contro....i

per questo voglio studiarlo per bene perchè sto meditando di usarlo anche in altri ambiti (nei miei programmi).