[VB.NET] Lentissimo ad inserire un record

[OrcaAssassina]

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

[wingman87]

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.

[OrcaAssassina]

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.

cosa mi consigli? Dimmi dove posso iniziare a vedere? C'è qualche settaggio in particolare da fare? Ciao e grazie

[gugoXX]

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)

...
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


Quando i comandi sono di sola lettura (SELECT), la transazione non e' necessaria.
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.

[wingman87]

Quindi ho detto una caxxata... Non sapevo che il modo in cui si mandano in esecuzione le query potesse influire tanto sui tempi.

[gugoXX]

Quindi ho detto una caxxata... Non sapevo che il modo in cui si mandano in esecuzione le query potesse influire tanto sui tempi.

Secondo me non l'hai detta. Non e' la query in se che da' problemi. E' il contesto che potrebbe darne.
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.

[OrcaAssassina]

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???

[gugoXX]

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.

[cdimauro]

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. ;)

[OrcaAssassina]

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. ;)

Tu quindi consigli le stored procedure???

Le stored procedure sono più veloci delle query eseguito all'interno del progetto????

Ciao e grazieeeee

[cdimauro]

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).

[OrcaAssassina]

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).

Quasi quasi, faccio tutto con le SP.....mi stai convincendo

Oggi pomeriggio faccio delle prove