|
|||||||
|
|
|
![]() |
|
|
Strumenti |
|
|
#1 |
|
Senior Member
Iscritto dal: Feb 2003
Messaggi: 2817
|
[VB.NET] Lentissimo ad inserire un record
Uso VB.NET + SQLEXPRESS2005
Fino a che il DB è nuovo ad inserire un record è velocissimo Quando inizio ad avere circa 4000 record, se inserisco un nuovo record è molto lento. Dopo potrebbere essere il problema, su VB.NET o su SQL???? Ciao e grazieeeeeeee
__________________
AMD 3700x --- ASUS X570 CROSSHEAR VIII HERO --- 4x 8GB Corsair Vengeance RGB PRO 3600 MHz --- SSD: Samsung 980Pro 1TBb --- EVGA RTX 2070 SUPER |
|
|
|
|
|
#2 |
|
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2780
|
Se c'è un problema (dico se c'è perché potrebbe essere normale, dipende da molti fattori) allora è sicuramente in SQLExpress perché VB dopo aver dato in pasto al DBMS la query da eseguire se ne lava le mani.
|
|
|
|
|
|
#3 |
|
Senior Member
Iscritto dal: Feb 2003
Messaggi: 2817
|
Ok
cosa mi consigli? Dimmi dove posso iniziare a vedere? C'è qualche settaggio in particolare da fare? Ciao e grazie
__________________
AMD 3700x --- ASUS X570 CROSSHEAR VIII HERO --- 4x 8GB Corsair Vengeance RGB PRO 3600 MHz --- SSD: Samsung 980Pro 1TBb --- EVGA RTX 2070 SUPER |
|
|
|
|
|
#4 |
|
Senior Member
Iscritto dal: May 2004
Città: Londra (Torino)
Messaggi: 3692
|
Ciao. 4000 record sono niente. Potresti iniziare a sentire qualche effetto nelle Insert dopo parecchie centinaia di migliaia, magari milioni.
L'unica cosa aggiuntiva che deve fare il DB e' l'aggiornamento della chiave primaria e degli indici, ma che non dovrebbe essere mai critico. Immagino che tu abbia diverse funzioni, in una tua classe (chiamata normalmente Database Tier, oppure Dtabase Access), ove hai confinato tutte le istruzioni che vanno ad interagire con il Database. Se non l'hai fatto te lo consiglio. Prova a seguire per ciascuna di queste funzioni il seguente schema (scrivo a pezzi con C#, ma ci sono le corrispondenti in VB.net) Codice:
...
using DBConnect myconn = (codice per aprire la tua connessione)
try
myconn.BeginTransaction
myconn.comando per il database
myconn.comando per il database
myconn.altro comando per il database
myconn.Commit
catch
myconn.Rollback
throw
finally
myconn.Close
end try
end using
Anche la myconn.Close non sarebbe necessaria perche' implicita nella chiusura del blocco USING (e' il distruttore di default della connessione), ma e' bene esplicitarla per chiarezza. Prova cosi'. Con il disposing corretto delle risorse non dovresti avere problemi.
__________________
Se pensi che il tuo codice sia troppo complesso da capire senza commenti, e' segno che molto probabilmente il tuo codice e' semplicemente mal scritto. E se pensi di avere bisogno di un nuovo commento, significa che ti manca almeno un test. |
|
|
|
|
|
#5 |
|
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2780
|
Quindi ho detto una caxxata... Non sapevo che il modo in cui si mandano in esecuzione le query potesse influire tanto sui tempi.
|
|
|
|
|
|
#6 | |
|
Senior Member
Iscritto dal: May 2004
Città: Londra (Torino)
Messaggi: 3692
|
Quote:
Immagina se per caso ogni operazione aprisse una connessione al database e non la chiudesse. La situazione diventerebbe presto appesantita. Sto ipotizzando che si sia in un caso simile, tutt'altro che raro a trovarsi, anche se senza codice e' difficile capirlo.
__________________
Se pensi che il tuo codice sia troppo complesso da capire senza commenti, e' segno che molto probabilmente il tuo codice e' semplicemente mal scritto. E se pensi di avere bisogno di un nuovo commento, significa che ti manca almeno un test. |
|
|
|
|
|
|
#7 |
|
Senior Member
Iscritto dal: Feb 2003
Messaggi: 2817
|
Metodo
Carichiamo un dataset contenente solo i dati che ci servono
Ogni singola riga viene viene caricata su degli UserControl inseriti allìinterno di un System.Collections.CollectionBase Popoliamo la lista e la passiamo ad un FlowLayoutPanel Dove nel flowlayoutpanel facciamo dei drag drop, inseriamo nuovi oggetti, eliminiamo oggetti esistenti Con pochi records nel db tutto funziona egregiamente (veloce) Nel momento in cui il database viene popolato con circa 5.000 - 10.000 records le prestazioni degradano pesantemente. Abbiamo effettuato le stesse select utilizzando stored procedure, ma non abbiamo notato nessun miglioramento Sapete darmi delle dritte su dove intervenire???
__________________
AMD 3700x --- ASUS X570 CROSSHEAR VIII HERO --- 4x 8GB Corsair Vengeance RGB PRO 3600 MHz --- SSD: Samsung 980Pro 1TBb --- EVGA RTX 2070 SUPER |
|
|
|
|
|
#8 |
|
Senior Member
Iscritto dal: May 2004
Città: Londra (Torino)
Messaggi: 3692
|
Allora il problema non e' nelle Insert, ma nelle Select...
Stored procedure o no, dovete concentrarvi su quelle, studiandole bene. Il lavoro di ottimizzazione di un database puo' essere complesso. Non e' raro che si debba ridisegnare aree mel progettate, con tutte le conseguenze di cambiare layout a una o piu' tabelle. Provate a cercare il punto critico, a spiegarlo, magari riusciamo ad aiutarvi.
__________________
Se pensi che il tuo codice sia troppo complesso da capire senza commenti, e' segno che molto probabilmente il tuo codice e' semplicemente mal scritto. E se pensi di avere bisogno di un nuovo commento, significa che ti manca almeno un test. |
|
|
|
|
|
#9 |
|
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
|
Ma soprattutto usando le stored procedure possono incapsulare il loro codice fornendo un'interfaccia esterna per le applicazioni.
Questo vuol dire che se dovesse cambiare la loro implementazione, o addirittura il design del database, il passaggio potrebbe essere poco traumatico, o addirittura completamente indolore. M'è capitato di recente con un mio progettino, che ha cambiato non poco la struttura interna del db: a livello di codice dei client non ho toccato una virgola, perché m'è bastato cambiare l'implementazione delle stored procedure usate.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys |
|
|
|
|
|
#10 | |
|
Senior Member
Iscritto dal: Feb 2003
Messaggi: 2817
|
OK
Quote:
Le stored procedure sono più veloci delle query eseguito all'interno del progetto???? Ciao e grazieeeee
__________________
AMD 3700x --- ASUS X570 CROSSHEAR VIII HERO --- 4x 8GB Corsair Vengeance RGB PRO 3600 MHz --- SSD: Samsung 980Pro 1TBb --- EVGA RTX 2070 SUPER |
|
|
|
|
|
|
#11 |
|
Senior Member
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
|
Le SP intanto sono precompilate in qualche forma di bytecode, e poi generalmente sono veloci praticamente quanto le normale query, se non di più alcune volte (ad esempio, gli engine SQL espongono API apposite in cui si passa soltanto il nome della S.P. e i suoi parametri; quindi non c'è alcuna fase di parsing della query: viene eseguita e basta).
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro @LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys |
|
|
|
|
|
#12 | |
|
Senior Member
Iscritto dal: Feb 2003
Messaggi: 2817
|
Ottimo
Quote:
Oggi pomeriggio faccio delle prove
__________________
AMD 3700x --- ASUS X570 CROSSHEAR VIII HERO --- 4x 8GB Corsair Vengeance RGB PRO 3600 MHz --- SSD: Samsung 980Pro 1TBb --- EVGA RTX 2070 SUPER |
|
|
|
|
|
| Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 04:47.




















