Il linguaggio Visual Basic di Microsoft
 

Edit dati su file

Antologiko 8 Dic 2015 21:19
Per un'applicazione monoutente che permette di aprire, visualizzare e modificare
dei documenti, qual è il modo più conveniente di gestire i dati su ******* o
comunque quali sono i pregi ed i difetti delle varie tecniche di seguito
indicate?

1. Carico tutti i dati in RAM, quindi salvo i cambiamenti solo alla fine.
2. Carico tutti i dati in RAM, ma salvo le modifiche man mano.
3. Tengo i dati in RAM solo per il tempo che servono (quando l'utente li
visualizza e/o modifica) e li scarico subito dopo, avendo così un continuo
flusso di lettura e/o scrittura su *******

Il primo caso mi pare il più semplice da implementare per due motivi:
- i dati possono essere caricati in RAM entro una struttura ad oggetti che
facilita la programmazione.
- i dati vengono letti e scritti su disco in un paio di passaggi.
Un problema che può diventare importante è la quantità di RAM necessaria,
specie nei casi in cui si tratta di documenti di grandi dimensioni.

Il secondo caso, condivide il pregio di poter caricare i dati in una struttura
ad oggetti, ma per quanto riguarda la scrittura dei dati su ******* a meno che
le modifiche non vadano sempre accodate al ******* ogni piccolo cambiamento in
un punto interno del ******* comporta diverse operazioni di lettura e scrittura
su disco.
Greg 8 Dic 2015 22:42
Il 08/12/2015 21:19:23 Antologiko ha scritto:
> Per un'applicazione monoutente che permette di aprire, visualizzare e
> modificare dei documenti, qual è il modo più conveniente di gestire i dati
su
> ******* o comunque quali sono i pregi ed i difetti delle varie tecniche di
> seguito indicate?
>
> 1. Carico tutti i dati in RAM, quindi salvo i cambiamenti solo alla fine.
> 2. Carico tutti i dati in RAM, ma salvo le modifiche man mano.
> 3. Tengo i dati in RAM solo per il tempo che servono (quando l'utente li
> visualizza e/o modifica) e li scarico subito dopo, avendo così un continuo
> flusso di lettura e/o scrittura su *******
>
> Il primo caso mi pare il più semplice da implementare per due motivi:
> - i dati possono essere caricati in RAM entro una struttura ad oggetti che
> facilita la programmazione. - i dati vengono letti e scritti su disco in un
> paio di passaggi. Un problema che può diventare importante è la quantità di

> RAM necessaria, specie nei casi in cui si tratta di documenti di grandi
> dimensioni.
>
> Il secondo caso, condivide il pregio di poter caricare i dati in una
> struttura ad oggetti, ma per quanto riguarda la scrittura dei dati su *******
a
> meno che le modifiche non vadano sempre accodate al ******* ogni piccolo
> cambiamento in un punto interno del ******* comporta diverse operazioni di
> lettura e scrittura su disco.

E il terzo caso cosa dice?

--
Greg
Antologiko 8 Dic 2015 23:34
> E il terzo caso cosa dice?

Mi pare il peggiore. Non riesco ad avere una rappresentazione in memoria dei
dati, e devo continuamente leggere e scrivere su disco.
Antologiko 8 Dic 2015 23:50
Il giorno martedì 8 dicembre 2015 23:34:43 UTC+1, Antologiko ha scritto:
>> E il terzo caso cosa dice?
>
> Mi pare il peggiore. Non riesco ad avere una rappresentazione in memoria dei
dati, e devo continuamente leggere e scrivere su disco.

Qual è la tua opinione?
Greg 8 Dic 2015 23:54
Il 08/12/2015 23:50:17 Antologiko ha scritto:
> Il giorno martedì 8 dicembre 2015 23:34:43 UTC+1, Antologiko ha scritto:
>>> E il terzo caso cosa dice?
>>
>> Mi pare il peggiore. Non riesco ad avere una rappresentazione in memoria dei
>> dati, e devo continuamente leggere e scrivere su disco.
>
> Qual è la tua opinione?


La mia opinione?
Hanno stamangianto, a speese dei tifosi, anche sul nuovos sito. Oppure
sono incapaci

--
Greg
Greg 8 Dic 2015 23:55
Il 08/12/2015 23:54:27 Greg ha scritto:
> Il 08/12/2015 23:50:17 Antologiko ha scritto:
>> Il giorno martedì 8 dicembre 2015 23:34:43 UTC+1, Antologiko ha scritto:
>>>> E il terzo caso cosa dice?
>>>
>>> Mi pare il peggiore. Non riesco ad avere una rappresentazione in memoria
>>> dei dati, e devo continuamente leggere e scrivere su disco.
>>
>> Qual è la tua opinione?
>
>
> La mia opinione?
> Hanno stamangianto, a speese dei tifosi, anche sul nuovos sito. Oppure sono
> incapaci

Io scrivo velcoe e poi guardo, non badare allì'ortografia

--
Greg
Luca D 9 Dic 2015 00:31
On Tuesday, December 8, 2015 at 9:19:25 PM UTC+1, Antologiko wrote:
> Per un'applicazione monoutente che permette di aprire, visualizzare e
modificare dei documenti, qual è il modo più conveniente di gestire i dati su
******* o comunque quali sono i pregi ed i difetti delle varie tecniche di
seguito indicate?
[...]

Così in senso astratto è difficile da dire... "documenti" cosa vuol dire?
formati strutturati oppure grossi "blob" di byte? che tipo di operazioni prevedi
di farci sopra?

Perchè se per esempio parlassimo di foto e filtri da applicare, per lo più non
puoi prescindere da avere l'intera immagine non compressa in memoria, ma se
parliamo di dati testuali/misti con una gerarchia strutturata, allora la cosa
potrebbe cambiare

Altra considerazione: la "fine" dei cambiamenti hai modo di controllarla in base
ad una serie di operazioni predeterminate da te, oppure semplicemente è
indefinita e si finisce quando l'utente decide che ha finito?

Perchè, per esempio, questo cambia drasticamente l'opportunità di andare verso
opzione 1 e 2, dove la prima la escluderei categoricamente visto che un
qualunque problema sul tuo software/altra guaio a caso sul PC potrebbe
potenzialmente perdere tutto il lavoro fatto.

ecc... ecc...
Antologiko 9 Dic 2015 19:14
> Perchè se per esempio parlassimo di foto e filtri da applicare, per lo
> più non puoi prescindere da avere l'intera immagine non compressa in
> memoria, ma se parliamo di dati testuali/misti con una gerarchia
> strutturata, allora la cosa potrebbe cambiare


Sono documenti che possono includere testo, immagini e in teoria anche elementi
au*****/video.


> Altra considerazione: la "fine" dei cambiamenti hai modo di controllarla
> in base ad una serie di operazioni predeterminate da te, oppure
> semplicemente è indefinita e si finisce quando l'utente decide che ha
> finito?

Il documento è strutturato in modo che si possa editare un tipo di elemento per
volta: blocchi di testo, immagini, ecc., quindi salverei alla fine delle
modifiche di ogni blocco, ma darei anche la possibilità all'utente di
anticipare il salvataggio tramite un pulsante.

> Perchè, per esempio, questo cambia drasticamente l'opportunità di andare
verso opzione 1 e 2, dove la prima la escluderei categoricamente visto che un
qualunque problema sul tuo software/altra guaio a caso sul PC potrebbe
potenzialmente perdere tutto il lavoro fatto.
>
> ecc... ecc...


Per quanto riguarda il salvataggio su ******* ciò che mi lascia perplesso è
che ogni volta che devo salvare le modifiche nel modo detto sopra, devo
"disfare" il ******* per riscrivere una sua parte interna. I programmi
commerciali fanno così? Oppure accodano in via provvisoria le modifiche, e poi
compattano il ******* alla chiusura?
Greg 9 Dic 2015 19:25
Il 08/12/2015 23:55:20 Greg ha scritto:
> Il 08/12/2015 23:54:27 Greg ha scritto:
>> Il 08/12/2015 23:50:17 Antologiko ha scritto:
>>> Il giorno martedì 8 dicembre 2015 23:34:43 UTC+1, Antologiko ha scritto:
>>>>> E il terzo caso cosa dice?
>>>>
>>>> Mi pare il peggiore. Non riesco ad avere una rappresentazione in memoria
>>>> dei dati, e devo continuamente leggere e scrivere su disco.
>>>
>>> Qual è la tua opinione?
>>
>>
>> La mia opinione?
>> Hanno stamangianto, a speese dei tifosi, anche sul nuovos sito. Oppure sono
>> incapaci
>
> Io scrivo velcoe e poi guardo, non badare allì'ortografia

E vado cosi veloce che sbaglio pure nh :(
Scusami!
La mia opinione sul tuo caso è di salvare il ******* ad ogni modifica; è
un solo utente, non sarà molta roba, qualsiasi cosa succeda, tu hai gia
salvato

--
Greg
Luca D 9 Dic 2015 22:39
On Wednesday, December 9, 2015 at 7:14:45 PM UTC+1, Antologiko wrote:

> Per quanto riguarda il salvataggio su ******* ciò che mi lascia perplesso è
che ogni volta che devo salvare le modifiche nel modo detto sopra, devo
"disfare" il ******* per riscrivere una sua parte interna. I programmi
commerciali fanno così? Oppure accodano in via provvisoria le modifiche, e poi
compattano il ******* alla chiusura?

Anche qui, dipende dal formato specifico... però per esempio potresti lavorare
su ******* temporaneo, e se anche il tuo documento è rappresentato da un solo
******* potresti spacchettarlo in più ******* temporanei con le varie parti.

In questo modo salvi le modifiche i tuoi blocchi separatamente, man mano che
lavorano, e poi fare l'operazione complessa di ricostruzione del *******
completo solo alla fine... tra l'altro così l'originale resta sempre intatto
fintanto che è in lavorazione, che è anche una forma di sicurezza in più se
vuoi, ma hai comunque qualcosa di persistente su ******* disk a scanso di
problemi
Nicola Ottomano 10 Dic 2015 15:46
Il 09/12/2015 22:39, Luca D ha scritto:

> Anche qui, dipende dal formato specifico... però per esempio potresti
lavorare su ******* temporaneo,
> e se anche il tuo documento è rappresentato da un solo ******* potresti
spacchettarlo in più ******* temporanei con le varie parti.
>
> In questo modo salvi le modifiche i tuoi blocchi separatamente, man mano che
lavorano,
> e poi fare l'operazione complessa di ricostruzione del ******* completo
solo alla fine...
> tra l'altro così l'originale resta sempre intatto fintanto che è in
lavorazione, che è anche una forma di sicurezza in più se vuoi,
> ma hai comunque qualcosa di persistente su ******* disk a scanso di problemi
>


+1

Sostanzialmente Office fa così.

Nicola

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Il linguaggio Visual Basic di Microsoft | Tutti i gruppi | it.comp.lang.visual-basic | Notizie e discussioni visual basic | Visual basic Mobile | Servizio di consultazione news.