Newsgroup: it.lavoro.professioni.webmaster
Titolo: consiglio prestazioni db

Salve a tutti,
Ho realizzato un template per le agenzie immobiliari in asp-access,
 fin'ora le città e le province di interesse le facevo inserire al cliente
....
ma ora mi è stato chiesto di inserire tutte le città di italia [sono > 8000
(già fatto)]
la mia applicazione era stata progettata per una singola agenzia, con un
modesto carico di lavoro
ho trovato adesso un cliente che ha 10 agenzie in franchising [un numero di
immobili circa 200 x 10 = 2000]
1 -considerando che spesso le operazioni coinvolgono join tra più tabelle :
province : 104 records
citta:  8524 records
immobili: circa 2000
2- considerando che, anche se sono 10 agenzie , operano in una  o due al
massimo tre province di 40000 abitanti di media , il che implica che non
dovrebbe avere un numero di visitatori elevato giornaliero
3- considerando che attualmente lo spazio web è su aruba
al fine di avere delle prestazioni decenti devo necessariamente cambiare db?
se le pagine di ricerca le sviluppo in .net posso avere dei miglioramenti
prestazionali ?
Vi chiedo dei consigli pratici, di chi magari ha avuto gli stessi problemi
..... :-)
Vi ringrazio anticipatamente per l'attenzione,
Salutissimi Rob

prestazionali ?
a mio avviso no.
-- 
abbraccio espedienti 365 giorni l'anno.
(generata da: 
http://www.phibbi.com/extra/gswe.php
)
il mio indirizzo email è valido ma è filtrato: per
essere certi che vi legga aggiungete la parola 
"newsgroup" al subject

 prestazionali ?
no puoi anche usare c o assembler ma se il db è fatto male sarà sempre lento 
non sarà .net a renderlo più rapido ma piuttosto gli indici sulle varie 
tabelle
-- 
Christian Paparelli
http://www.ithost.ch
 


I'm sorry what means ? [che significa tuning ...]
scusate l'ignoranzità, l'ignorantezza ed infine l'ignorantità [questa l'ho 
sentita l'altro ieri ..... :-)]
saluti e baci
rob

 no piuttosto devi dedicare tempo al tuning dello stesso
In un caso come questo cosa si potrebbe fare per migliorare le 
prestazioni del db? (in linea generale dato che non conosciamo le query 
in questione)

 sentita l'altro ieri ..... :-)]
buona lettura
http://support.microsoft.com/?kbid=209126


 del db? (in linea generale dato che non conosciamo le query in questione)
Visto che è in hosting su Aruba e che usa Access mi auguro
solo di non condividere lo stesso server ;)
-- 
bye
luke
[ 
www.vastosansalvo.it
 ]

 del db? (in linea generale dato che non conosciamo le query in questione)
come fai a fare l'ottimizzazione delle tabelle con i relativi indici senza 
avere le query??
no query no party :-D


I'm sorry what means ? [che significa tuning ...]
con tuning si intende letteralmente sintonia, ma gergalmente, più o
meno, affinamento...  sai quando cerchi una stazione radio onde corte
e giri piano piano con molta attenzione un grosso manopolone
analogico?  ecco, quello è il tuning.
quindi devi costruire bene il tuo db, normalizzando dove serve,
denormalizzando dove serve...  dovrai scrivere le query in forma
corretta...  se usi access probabilmente ti converrà usare
direttamente le "query" che puoi creare "dentro" access e settarci
sopra direttamente i recordset passandogli i parametri adeguati..


 analogico?  ecco, quello è il tuning.
ma ROTFL ne ho sentite di tutti i colori ma questa devo incorniciarla :-D


Vi ringrazio tutti del vivo interesse dimostrato ...
se sapevo che era lo stesso tuning dello stereo non lo chiedevo .... :-)
saluti rob 


Non riesco proprio a capire come tu abbia fatto a progettare 
un'applicazione senza conoscere le query.
:asd:
Cmq il ragionamento che fai tu sul poco traffico e' ok.
Ma se per sfortuna hai successo che fai?
acCESS, nonostante M$ dichiari il contrario, inizia a sclerare 
pesantemente sopra le 15 connessioni concorrenti avendo un supporto per 
la concorrenza abbastanza scadente.
Inoltre e' basato su singolo file che tende a crescere se ci sono molte 
operazioni DML.
Ah si, non so se e' ancora cosi' nella versione xp, ma fino alla 2000 
l'ottimizzazione era basata su regole (per la serie c'e' un indice sul 
campo di where lo usa anche se deve trovare un record in un set di 4 :\).
Quando lavoravo con questo "database" (sput sput) avevo previsto una 
politica di ricompressione periodica senza la quale nel giro di un mese 
mi ritrovavo un file di 20 MB contenente 20k di dati allocato sul server.
Valuta a questo punto se usare un database meno rompi***o.
Aruba dovrebbe fornire MySql che ha anche lui i suoi problemucci ma 
almeno somiglia di piu' ad un vero RDBMS.
E cmq la traduzione dal dialetto acCESS a MySql non e' per nulla 
problematica.
Bye
Neo

 problematica.
ok allora mi trasformi rapidamente in MySQL una query cros-tab usando 
l'operatore pivot :-D
Come vedi mysql è un buon prodotto ma sorry metterlo su un piedistallo non 
mi sembra corretto soprattutto se in circolazioni esistono database degni di 
tale nome ed inoltre la naturale evoluzione è da access a mssql


 un'applicazione senza conoscere le query.
Non sono io che ho fatto il tutto :D
La mia era solo una domanda per sapere se esistono delle direttive da 
seguire in generale per diminuire il + possibile il carico del db. Ad es 
correzioni ad errori che commettono spesso quelli alle prime armi.

>no query no party :-D
e a questo proposito, secondo te, usando access č meglio creare le
query "dentro" access stesso o creare il codice sql dinamicamente e
poi passarlo alla connessione per settare un recordset?
-- 
abbraccio espedienti 365 giorni l'anno.
(generata da: 
http://www.phibbi.com/extra/gswe.php
)
il mio indirizzo email č valido ma č filtrato: per


problematica.
infatti se uno si scrive le query in codice basta sostituire la
stringa di connessione e funziona tutto subito.  questo è uno dei
motivi per i quali in genere non uso le query che si fanno "dentro"
access.
comunque mi pare che su mysql non funzioni select in.  pazienza, un
buon incentivo ad usare dei join fatti bene.
-- 
abbraccio espedienti 365 giorni l'anno.
(generata da: 
http://www.phibbi.com/extra/gswe.php
)
il mio indirizzo email è valido ma è filtrato: per


 poi passarlo alla connessione per settare un recordset?
per una questione di performance č meglio creare le query all'interno di 
access in quanto le stesse verranno compilate e ottimizzate e saranno molto 
piů rapide rispetto a query dinamiche
I tempi di esecuzione posso peggiorare di oltre il 7000% con le query 
dinamiche questo perchč non č possibile stabilire un piano di esecuzione se 
non in fase di esecuzione



Dipende a mio avviso dal numero di richieste, nel suo caso io mettrey le 
query solo per le città più importanti
Ciao
Marcello


.. poco male , se non erro le operazioni a livello insiemistico sono le più 
pesanti !!!
se si struttura bene il db [normalizzato] e con delle opportune [e ripeto 
opportune] ridondanze
alcune operazioni possono risultare molto più veloci ....
[non pensavo di creare così tanto scalpore ..... vi ringrazio tutti]
saluti rob 


Ho buone notizie per te: MySQL dalla versione 4.1 supporta le subquery.
Mao
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

tanks
saluti rob