Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.lang.visual-basic > #18618 > unrolled thread

Edit dati su file

Back to article view | Back to it.comp.lang.visual-basic

Contents

  Edit dati su file Antologiko <antologiko@gmail.com> - 2015-12-08 12:19 -0800
    Re: Edit dati su file Greg <greg@alicie.com> - 2015-12-08 22:42 +0100
      Re: Edit dati su file Antologiko <antologiko@gmail.com> - 2015-12-08 14:34 -0800
        Re: Edit dati su file Antologiko <antologiko@gmail.com> - 2015-12-08 14:50 -0800
          Re: Edit dati su file Greg <greg@alicie.com> - 2015-12-08 23:54 +0100
            Re: Edit dati su file Greg <greg@alicie.com> - 2015-12-08 23:55 +0100
              Re: Edit dati su file Greg <greg@alicie.com> - 2015-12-09 19:25 +0100
    Re: Edit dati su file Luca D <antaniserse@yahoo.it> - 2015-12-08 15:31 -0800
      Re: Edit dati su file Antologiko <antologiko@gmail.com> - 2015-12-09 10:14 -0800
        Re: Edit dati su file Luca D <antaniserse@yahoo.it> - 2015-12-09 13:39 -0800
          Re: Edit dati su file Nicola Ottomano <spammami@nicolaottomano.it> - 2015-12-10 15:46 +0100

#18618 — Edit dati su file

Per un'applicazione monoutente che permette di aprire, visualizzare e modificare dei documenti, qual è il modo più conveniente di gestire i dati su file, 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 file.

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 file, a meno che le modifiche non vadano sempre accodate al file, ogni piccolo cambiamento in un punto interno del file comporta diverse operazioni di lettura e scrittura su disco.

[toc] | [next] | [standalone]

#18619

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 
> file, 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 file.
>
> 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 file, a 
> meno che le modifiche non vadano sempre accodate al file, ogni piccolo 
> cambiamento in un punto interno del file comporta diverse operazioni di 
> lettura e scrittura su disco.

E il terzo caso cosa dice?

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#18620

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

[toc] | [prev] | [next] | [standalone]

#18621

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?

[toc] | [prev] | [next] | [standalone]

#18622

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

[toc] | [prev] | [next] | [standalone]

#18623

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

[toc] | [prev] | [next] | [standalone]

#18626

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 file ad ogni modifica; è 
un solo utente, non sarà molta roba, qualsiasi cosa succeda, tu hai gia 
salvato

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#18624

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

[toc] | [prev] | [next] | [standalone]

#18625

> 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 audio/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 file, ciò che mi lascia perplesso è che ogni volta che devo salvare le modifiche nel modo detto sopra, devo "disfare" il file per riscrivere una sua parte interna. I programmi commerciali fanno così? Oppure accodano in via provvisoria le modifiche, e poi compattano il file alla chiusura?

[toc] | [prev] | [next] | [standalone]

#18627

On Wednesday, December 9, 2015 at 7:14:45 PM UTC+1, Antologiko wrote:

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

Anche qui, dipende dal formato specifico... però per esempio potresti lavorare su file temporaneo, e se anche il tuo documento è rappresentato da un solo file, potresti spacchettarlo in più file 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 file 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 hard disk a scanso di problemi

[toc] | [prev] | [next] | [standalone]

#18628

Il 09/12/2015 22:39, Luca D ha scritto:

> Anche qui, dipende dal formato specifico... però per esempio potresti lavorare su file temporaneo,
> e se anche il tuo documento è rappresentato da un solo file, potresti spacchettarlo in più file 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 file 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 hard disk a scanso di problemi
>


+1

Sostanzialmente Office fa così.

Nicola

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.lang.visual-basic

csiph-web