Il modo migliore per interrogare i dati dal database e quindi modificarli

Se hai intenzione di interrogare e aggiornare, andrei con Reader. È un po 'più efficiente e sembra che tu non abbia bisogno di alcuna caratteristica DataTable.

On Reader usa ordinale (non il nome della colonna) per un riferimento un po 'più veloce.

Le connessioni sono raggruppate in modo da aprire e chiudere una connessione è veloce.

MySqlConnection con = new MySqlConnection(.... 
try 
{
     con.Open();
     using(MySqlCommand cmd = con.CreateCommand())
     {
         Int    data1;
         String data2;
         cmd.CommandText = .....;  //or better parameterized query
         using(MySqlReader rdr = cmd.ExecuteReader())
         {
            data2 = rdr.GetInt(0); 
            data2 = rdr.GetString(1);
         }
         // rdr should be closed so you can reuse the cmd  
         // do any cacls you need 
         cmd.CommandText = "update table ....." + data;  //or better parameterized query
         cmd.ExecuteNonQuery();
     }
}
catch(SQLexception Ex) 
{
}
finally
{
    if(con.IsOpen)   // not the actual syntax - look it up
       con.Close();
}

Se hai bisogno di preoccuparti dei dati modificati tra la lettura e la scrittura, potresti aver bisogno di una transazione

E dovresti usare query / aggiornamenti parametrizzati a meno che non siano i dati sotto il tuo controllo che possono pulire le iniezioni

Anche StoredProduces potrebbe essere un po 'più veloce. Ma se si accede a una riga da un PK diretto al tavolo sarà piuttosto veloce.

Se la query non è dal PK, recuperare il PK e utilizzarlo nell'aggiornamento

Quando si tratta di prestazioni del DB, le soluzioni migliori sono estremamente dipendenti dal sistema DB che si sta utilizzando. Posso darti alcuni suggerimenti su come ottimizzare il tuo caso per MS Access, per il server MS SQL avrai probabilmente bisogno di un approccio completamente diverso.

1. Per l'accesso con un singolo utente, mantieni il file del database localmente

Se si desidera mantenere il file db su un'unità di rete per i backup notturni del server, ma non si ha la necessità di accedere al database da un secondo utente contemporaneamente, è sufficiente copiarlo da una cartella di rete prima del l'elaborazione inizia, esegue l'elaborazione e la copia in un secondo momento. Questo rilascia il tuo programma da qualsiasi sovraccarico di rete.

2. Non utilizzare ADO.DB. Utilizza il classico ADO o DAO!

Questo può sembrare molto vecchio e obsoleto, ma ADO e DAO (che sono completamente disponibili in VB.NET come componenti COM su tutti i moderni sistemi Windows) possono essere fino a 20 volte più veloci per la lettura e l'elaborazione batch; aggiornare gli scenari su Access rispetto a ADO.DB, a causa del sovraccarico aggiuntivo di astrazione. Questo è almeno quello che ho misurato durante la creazione di questo tipo di applicazioni. Inoltre, queste API meno recenti contengono il concetto di un recordset (che funziona in modo simile al concetto di un cursore in altri database SQL), ma AFAIK non è supportato da ADO.DB. Recordset ti permetterà di navigare verso un determinato record, leggerlo, modificarlo e scriverlo all'interno della stessa connessione e "transazione" (qualunque cosa quest'ultima significhi in MS Access).

Alcuni suggerimenti generali (oltre al solito "misura in cui il tuo vero collo di bottiglia è"):

Come regola generale, valida anche per diversi database: per il tipo di scenario, più lo storage è leggero, più veloce è il tuo programma. L'approccio più veloce è spesso quello che puoi fare in memoria, il secondo più veloce sono i file flat, quindi le soluzioni DB leggere come MS Access o SQLite e infine (spesso più lentamente di un ordine di grandezza) i database client / server pesanti con gestione completa delle transazioni.

Naturalmente, questa è solo una linea guida molto approssimativa: la prestazione finale che otterrai dipenderà dai dettagli cruenti della tua implementazione e dall'hardware e dall'amplificazione disponibili; di rete.

Considera di scrivere la logica per fare comparazioni e aggiornamenti all'interno delle stored procedure nel tuo database. È quindi possibile richiamare le stored procedure utilizzando SqlCommand .

Se si presta attenzione a come strutturare le query nelle stored procedure, non ha quasi nessun sovraccarico rispetto all'esecuzione di più query da un'applicazione, ma consente di risparmiare la latenza di più query.

L'unico svantaggio è che dovrai rifare molta logica del tuo database quando esegui la migrazione a un nuovo DBMS.