VB.NET connessione a database on line o no?

[Rosy23]

Scusate ma se voi doveste fare un progetto in cui aver la possibilità di scegliere se utilizzare dei dataset o aprire la connessione a un database all'inizio del programme e chiuderla alla fine quale scegliereste?

Mi spiego meglio, per creare un programma per piccole aziende con database (circa una 80 di tabelle con max di record per tabella 5000/10000 )
a cui si accede in rete di max 5/8 utenti massimo per ovviare ai vari problemi di lock delle tabelle in scrittura, pesantezza elentezza dei dati ecc fareste una connessione aperta inizialmente e chiufdendola alla fine e ogni volta che ho bisogno di dati faccio delle query di lettura al database idem per la variazione, oppure carichereste in un ddataset tutte le tabelle necessarie con ovvio rallentamento iniziale ma migliori prestazioni in fase di operatività a connessione chiusa?

E per il problema della sovrapposizione e lockkaggio dei record come impostereste la faccenda?
Domanda articolata e troppo complessa forse?
Lo so ma ho un grosso dubbio e vorrei condividere le idee e la mia limitata esperienza con voi.

Grazie a tutti per l'attenzione.

[alka]

Non è possibile indicare una soluzione che sia ottimale in assoluto. Tutto dipende dalla mole di dati che deve essere elaborata, dal database utilizzato e dalla bontà della connessione, oltrechè alle operazioni da svolgere sui dati stessi.

Io suggerisco l'impiego di un database di tipo client/server per evitare la necessità di effettuare dei lock e unlock dei record; le modifiche ai dati vengono gestite sfruttando delle transazioni affinchè gli utenti possano operare in un contesto valido e confermare in blocco elaborazioni multiple nella loro interezza, in modo atomico.

A parte questo, l'esigenza di scaricare i dati e lavorare offline per sincronizzarsi in un secondo momento concede molti vantaggi; nonostante il consumo di memoria e il tempo di caricamento iniziale, permette di liberare preziose risorse sul server, lavorare in modalità disconnessa sui dati ottenendo anche ordinamenti, filtri e altro ancora, per poi sincronizzarsi con il server riducendo il traffico di rete.

Nulla toglie comunque che si possano adottare soluzioni intermedie, connesse e disconnesse, a seconda delle occasioni.

Magari vale la pena focalizzare l'obiettivo che stai cercando di raggiungere per definire meglio le informazioni che ti servono effettivamente.

Ciao!

[Rosy23]

< Io suggerisco l'impiego di un database di tipo client/server per evitare la necessità di effettuare dei lock e unlock dei record; le modifiche ai dati vengono gestite sfruttando delle transazioni affinchè gli utenti possano operare in un contesto valido e confermare in blocco elaborazioni multiple nella loro interezza, in modo atomico. >

Allora il punto è anche quello cercavamo di stabilire anche quale sia il miglior DB da utilizzare ma non solo per una questione di performance ma anche una questione di prezzo.
Se si andasse su un DB Oracle certamente garantirebbe un'affidabilità eccezionale, ma di contro costerebbe molto e le piccole aziende non potrebbero accollarsi una spesa cosi' rilevante per la modesta mole di dati da trattare.
Ripeto si tratta di decine di migliaia di record e di scorrere tra di essi facendo ricerche su che so tutti i contratti si di un determinato cliente i pagamenti effettuati le schede (diciamo diverse schede ma sull'ordine della decina) di quel cliente ecc..
Mi chiedevo è il caso di lavorare con Dataset solo per questa mole di dati?
Allora se l'attenzione andasse ad una connessione diversa (tipo aprirla all'inizio e chiuderla alla fine del lavoro (quando si termina il programma) che cosa coporterebbe dal lato della sicurezza dei dati e della perdita dei dati?

Mi spiego per scegliere su quale delle 2 tecnologie (o ideologie) applicare noi stavamo + vedendo in rapporto a come gestire la non perdita dei dati.
Del tipo se lavorassimo senza dataset si pnsava di applicare un blocco in scrittura ai record una volta che sono stati letti da altri, ma ci sarebbe il problema delle multiconnessioni che magari un DB non potente (abbiamo escluso Oracle) gestisce tranquillamente ma altri DB meno potenti tipo Access o altri non gestiscono in modo adeguato o quasi per nulla multiconnessioni di 4 5 utenti contemporanei...

Ma se lavorassimo con Dataset avremmo il vantaggio di non gestire le multiconnessioni ma lo svantaggio della perdita di dati se 2 o + utenti decidessero di modificare lo stesso record, perchè i cambiamenti riguarderebbero solo uno di essi...

Quindi i problemi sostanziali sono 2.
1) Che DB utilizzare che non abbia costi rilevanti per le piccole aziende
2) Che metodologia utilizzare che gestisca in modo assolutamente ottimale i blocchi in lettura o con altri mezzi dei record 'occupati'.

Grazie tantissime dell'attenzione per questo 'poema' ...
Ciao.

[alka]

Originariamente inviato da Rosy23
Allora il punto è anche quello cercavamo di stabilire anche quale sia il miglior DB da utilizzare ma non solo per una questione di performance ma anche una questione di prezzo.

Vale lo stesso discorso: non esiste il MIGLIORE DATABASE in assoluto, ma il database più adatto a specifiche esigenze.

Come vedi, anche tu hai posto questioni di performance e di prezzo; puoi trovare un buon compromesso tra le due, ma ovviamente non sempre quello che eccelle in un campo lo fa anche nel secondo.

Originariamente inviato da Rosy23
Se si andasse su un DB Oracle certamente garantirebbe un'affidabilità eccezionale, ma di contro costerebbe molto e le piccole aziende non potrebbero accollarsi una spesa cosi' rilevante per la modesta mole di dati da trattare.

Inoltre, devi tenere conto della complessità medio/alta di quel particolare database, che richiede documentazione e formazione per poter essere sfruttato al meglio.

La spesa è ovviamente equiparata a questi aspetti.

Originariamente inviato da Rosy23
Ripeto si tratta di decine di migliaia di record e di scorrere tra di essi facendo ricerche su che so tutti i contratti si di un determinato cliente i pagamenti effettuati le schede (diciamo diverse schede ma sull'ordine della decina) di quel cliente ecc..
Mi chiedevo è il caso di lavorare con Dataset solo per questa mole di dati?

Occorre sempre tenere a mente che, lavorando con database client/server, è sempre possibile una mediazione: attraverso una query SQL ottimizzata, puoi estrarre solo alcune righe del database (ad esempio, quelle relative ad un determinato cliente in merito alle fatture emesse) e memorizzarle in un DataSet lato client; non hai bisogno di scaricare tutti i dati di quel cliente, ma solo quelli su cui intendi, o potresti, lavorare, avendo cura poi di inviare le modifiche al server, operazione che viene portata a termine correttamente siccome è possibile basarsi su una chiave primaria.

Originariamente inviato da Rosy23
Allora se l'attenzione andasse ad una connessione diversa (tipo aprirla all'inizio e chiuderla alla fine del lavoro (quando si termina il programma) che cosa coporterebbe dal lato della sicurezza dei dati e della perdita dei dati?

Parlando di database di tipo client/server, non c'è alcun rischio di perdita di dati o sicurezza nel tenere aperto una connessione: semplicemente, si tratta di avere un canale di comunicazione sempre pronto con il server per inviare statement SQL e interrogare la base dati; siccome è il server che si occupa di gestire il file contenente tali dati, non sono necessari lock di alcun tipo poichè tutto viene gestito, nel modo corretto, dal server, con meccanismi di ridondanza, controllo e validazione dei dati, in massima sicurezza.

Originariamente inviato da Rosy23
Mi spiego per scegliere su quale delle 2 tecnologie (o ideologie) applicare noi stavamo + vedendo in rapporto a come gestire la non perdita dei dati.

La perdita dei dati è un evento ricorrente quando si lavora con database basati su file (file based) come Access, dBase e simili; con database client/server, quali MySQL, SQL Server, FireBird, InterBase e così via, questo inconveniente è ridotto al minimo poichè il server gestisce copie di sicurezza della base dati e, inoltre, è possibile raggiungere un maggior grado di efficienza mettendo un gruppo di continuità sulla macchina scelta come server, cioè quella a cui vengono inviate le richieste da parte dei vari client collegati per ottenere dati da elaborare (o per apportare modifiche agli stessi dati).

Originariamente inviato da Rosy23
Del tipo se lavorassimo senza dataset si pnsava di applicare un blocco in scrittura ai record una volta che sono stati letti da altri, ma ci sarebbe il problema delle multiconnessioni che magari un DB non potente (abbiamo escluso Oracle) gestisce tranquillamente ma altri DB meno potenti tipo Access o altri non gestiscono in modo adeguato o quasi per nulla multiconnessioni di 4 5 utenti contemporanei...

Credo che questo discorso esuli dal componente (DataSet, DataReader e altro ancora) adottato per l'accesso alla base dati; il problema del blocco dei record avviene solo con database basati su file come Access poichè ciascun utente, accedendo direttamente al file, impedisce ad altri di scrivere sullo stesso record; nei database client/server, non si accede al file ma si colloquia con un server che è in grado di accettare richieste senza blocchi e di convogliarle nella base dati che esso gestisce.

Poi, che si voglia scaricare in un DataSet una serie di record ricevuti, oppure che si intenda operare direttamente senza copia locale di record con un DataReader, è una scelta che dipende da ciò che si deve fare, ma esula comunque dal discorso della piattaforma database selezionata.

Originariamente inviato da Rosy23
Quindi i problemi sostanziali sono 2.
1) Che DB utilizzare che non abbia costi rilevanti per le piccole aziende

Io uso FireBird, è free e OpenSource, ma ce ne sono talmente tanti...

Originariamente inviato da Rosy23
2) Che metodologia utilizzare che gestisca in modo assolutamente ottimale i blocchi in lettura o con altri mezzi dei record 'occupati'.

Questo dipende dall'ambito di utilizzo dei dati stessi nelle varie occasioni.

Ciao!

[cassano]

pero se nn sbaglio e in tal caso chiedo scusa con l'oggetto datareader nn si possono apportare modifiche al db ,oppure sbaglio ???

[alka]

Originariamente inviato da cassano
pero se nn sbaglio e in tal caso chiedo scusa con l'oggetto datareader nn si possono apportare modifiche al db ,oppure sbaglio ???

E' l'oggetto Command che definisce quello che si deve fare in termini di SQL; il DataReader è solo uno strumento per leggere i dati.

Ciao!

[cassano]

ok pero con il dataset c'è la possibilità di modificare o aggiungere righe e successivamente aggiornare il db ,invece usando l'oggetto dataread si ha la possibilita di aggiornamento solo tramite l'oggetto command

[alka]

Originariamente inviato da cassano
ok pero con il dataset c'è la possibilità di modificare o aggiungere righe e successivamente aggiornare il db ,invece usando l'oggetto dataread si ha la possibilita di aggiornamento solo tramite l'oggetto command

Sì, ma non capisco cosa c'entra questo con l'argomento in esame.
:master:

[cassano]

no era una mia curiosità che durante il discorso mi avete fatto venire

[alka]

Originariamente inviato da cassano
no era una mia curiosità che durante il discorso mi avete fatto venire

Comprendo la tua curiosità, ma non è che si può passare tranquillamente da un argomento all'altro: è necessario attenersi all'argomento di cui si sta parlando, altrimenti chi ha aperto la discussione non ci capisce più nulla e trova solamente altri messaggi inquinanti che non risolvono il problema proposto.

Se ti viene una curiosità a partire da una discussione, aprine una nuova e chiedi lì, altrimenti rischi solamente di far chiudere questa lasciando i volenterosi che l'hanno aperta e portata avanti...a bocca asciutta.