Newsgroup: it.comp.lang.visual-basic
Titolo: gestire grossi volumi di dati

salve a tutti!
mi ritrovo a gestire una database in cui una tabella ha circa 6.000.000 di
record.
al momento per fare delle prove ho caricato questi dati in un database
access (!)
facendo delle semplici query vedo che il tempo di restituzione dei dati è
sempre compreso tra i 60-80 secondi, sia che la query mi restituisca un solo
record sia che me ne restituisca 20.000.
il database per ora è in locale. in futuro sarà in rete e molto
probabilmente utilizzerò MySQL.
volevo sapere se questa tremenda lentezza è dovuta interamente ad access
oppure devo prendere delle accortezze per maneggiare queste quantità di
dati?
Questo è parte del codice utilizzato al momento:
(La query SQL è semplicissima nessun join solo un where e un solo campo in
select)
----------------------------------------------------------------------------
------------------------------
Set dbConn = New ADODB.Connection
Set rs = New ADODB.Recordset
With dbConn
    .CursorLocation = adUseServer
    .Open "PROVIDER=Microsoft.Jet.OLEDB.4.0;Data Source=" + pathDb + ";"
End With
rs.Open sSQL, dbConn, adOpenForwardOnly, adLockReadOnly
----------------------------------------------------------------------------
--------------------------------
con questi tempi il DB risulta inutilizzabile, la risposta dovrebbe stare
sotto agli 8-10 secondi
grazie a tutti
ciao!!
marco

 select)
A prescindere dal database, indicizzare la tabella diventa
*fondamentale*.
-- 
ciao, hal

 ha scritto nel messaggio
news:3904i1F...@individual.net...

Ciao Marco.
Le considerazioni in merito sono decisamente molte.
Sicuramente Access(JET) ha dei limiti, il più grosso tra i quali è
l'impossibilità di lavorare Server_Side con i dati.
Questo implica che anche usando la struttura FE_BE(o Client Server)
con JET l'elaborazione del Recordset avviene in Locale.
Quì ora entrano in gioco l'ottimizzazione delle Tabelle, la normalizzazione
e la corretta Indicizzazione dei Campi.
Tutti questi accorgimenti, e sicuramente altri, ti aiutano ad ottimizzare il
lavoro del DB_ENGINE di JET.
Ciò premesso, ritengo che nella tua condizione la soluzione più performante
non sia quella di usare MySQL, ma di appoggiarti a MSDE, nuovo motore
del Database SQL, che soddisfa in modo professionale tutte le esigenze fino
a qualche decina di Utenti(dipende dalla versione con MSDE 2000 credo siano
8
contemporanei).
Questo motore viene distribuito con il pacchetto Office, pertanto è fruibile
da parte di chi ha regolare licenza.
E' forse superfluo dire che è lo stesso Motore di SQL_SERVER, pertanto
supporta
ADP perfettamente.
Con questo sistema, che ti invito a valutare con molta attenzione, risolvi
egregiamente
i problemi di estrazione dati.
Alla base ti tutto c'è sempre un gran lavoro di Ottimizzazione della
gestione dati.
Con MSDE hai la possibilità di usare SP che elaborano Server_Side il
recordset
inviando al Client solo i dati risultanti...... ecc...ecc...ecc...!
Ciao
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.mantuanet.it/alessandro.baraldi/
---------------------------------------------------------------------------

probabilmente utilizzerò MySQL.
Sai che va licenziato, vero? Se proprio devi usare qualcosa che non
sia MSDE, punta su PostgreSQL (l'attuale versione gira anche sotto
Win32).
--
Ciao!
Luca Menegotto

 Luca Menegotto

 ha scritto nel messaggio
news:422adff3$0$6308$5fc...@news.tiscali.it...

[cut]
ma in futuro il db dovrebbe essere consultabile anche in rete (asp+VBscript)
oltre che da applicazioni VB, quindi gli utenti saranno più di 8
dici che MySQL non va bene in quanto a prestazioni?
volendo potrei utilizzare anche oracle ma preferisco evitare di usarlo (in
quanto è su un server non gestibile da me ed ha prestazioni alquanto
scadenti)
grazie per l'aiuto!
ciao
marco


 tutti
non credo che le cose stiano esattamente cosi', o almeno, non cosi'
semplicemente. credo dipenda dal tipo del tuo programma ecc. ecc.
guarda sul sito di mysql.
ciao, j.

 scadenti)
Problemi di MySQL non risiedono nelle sue prestazioni, peraltro ottime,
ma nel fatto che *non* è un dbms...
Leggi e "rabbrividisci":
http://sql-info.de/mysql/gotchas.html
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 Ciao.
Ciao,
Andrea

 Mi pare un pň fortina questa
Sě, era volutamente esagerata, anche se MySQL č in effetti troppo 
limitato per essere usato seriamente. Se poi ci aggiungiamo quelle
"caratteristiche" di funzionamento citate nel sito del quale ho postato
il link...


 ciao, j.
ciao e GRAZIE A TUTTI per i consigli!
marco