Newsgroup: it.comp.lang.visual-basic
Titolo: [BT] Formati files fatti bene e meno bene

In questi giorni sto lavorando molto alle mie applicazioni e, visto
che sono in montagna solo col portatile e non ho dietro un server con
NetBSD + PostgreSQL, lavoro su un file di Access a cui accedo via
ADO+ODBC.
La cosa mi e' comoda perche' cosi' man mano che introduco dei dati nel
database li posso controllare al volo "a occhio".
Ogni tanto faccio un "Compatta Database" da dentro Access e ogni tanto
mi faccio una copia di backup del database e, siccome i files di
Access diventano di dimensioni indecenti abbastanza velocemente, i
backup li faccio zippati.
A guardare quanto si zippano i files di Access mi rendo conto di
quanto puo' essere fatto male un formato di salvataggio di
un'applicazione.
Qualche anno fa mi misi a lavorare ad un cad elettronico. Qualcosa
tipo OrCAD, se qualcuno di voi ha avuto il dispiacere di utilizzarlo.
Non avevo grosse pretese: volevo un editor di schemi elettronici
funzionale e facile da usare e un editor di pcb manuale, senza
autoroute, ad esempio. Siccome all'epoca avevo del tempo da spendere
in analisi preliminari del software, avevo studiato un formato di
salvataggio dei files che fosse compatibile in avanti e all'indietro
con il mio cad: avevo studiato un sistema che permetteva ad una
versione vecchia del cad di aprire anche files salvati da versioni
successive, ignorando semplicemente i dati che non era in grado di
gestire. Avevo studiato un formato file ottimizzato quasi al bit,
tant'e' che zippandolo si arrivava al massimo a risparmiare un 4/5%
della dimensione originaria del file. Che, comunque, era sempre tanto
piccolo che era inutile volerlo zippare =)
Oggi sono rimasto davvero male quando ho visto che un file di Access
di 720kB .mdb si zippa in un file di 66kB .zip: siamo a 11:1. Poi mi
e' venuto in mente quando ho fatto il listino prezzi nuovo: un file di
3.4MB di Word si zippa in 620kB qua e' 6:1... Per non parlare dei
files di Excel per la tesi di Francy: da 2.5MB di partenza, ho zippato
in poco piu' di 500kB: anche qui, 5:1.
A parte tentare inutilmente di riempire dischi fissi da 40GB, mi dite
a cosa puo' servire salvare cosi' tanta roba inutile e ridondante in
un file?
Oggi, dopo alcuni anni passati dai pastrocchi sul BBCad e sul suo
splendido formato di salvataggio, nella mia suite di applicazioni ho
scelto di salvare tutto in plain text, con alcuni tag --sempre in
testo chiaro-- che mi permettono, eventualmente, di poter modificare
uno qualsiasi dei miei files in qualsiasi sistema operativo con un
qualsiasi editor di testo. Pero', *almeno*, ho deciso di usare un
formato file relativamente ingombrante per comodita' d'uso: gli
applicativi di Microsoft salvano in formato "chiuso" e mascherato...
Poi si potrebbe parlare dei formati grafici .cdr, .psp e .psd --il
piu' record dei record...--, ma sparare sulla croce rossa non sta
tanto bene...
Saluti.
-- 
      Gianni "bugbarbeq" Rondinini, 25, RA, 0.68, 152
  VBR - Vero Birro Romagnolo®, diffidate dalle imitazioni!
Nike Air Up Tempo Sad Walker -- Kawasaki "Gas Gas" ZZ-R 1100
 ICQ# 36893168 - IRCNet: bugbarbeq, @ on #linux-it & #NetBSD
   On contrary of popular belief, Unix *IS* user friendly:
    it just appears to be selective who it is friend with

è la legge del mercato...
sempre più mips, sempre più bps...
e nessuno pensa più ad ottimizzare nulla...
anzi, non si ottimizza perché si sa che tra 6 mesi i mips saranno il
doppio...
io stesso faccio un uso smodato dei file sequenziali, tanto con
l'hardware di oggi ci metto un microsecondo a leggerli e c'è talmente
tanta ram che non mi preoccupo più degli array...
se si ottimizzasse il software (exe, dati, ecc.) potremmo ancora usare
un 486 e 16 mega di ram...
ed infatti i prg 'scritti bene' girano in modo adeguato anche su
piattaforme poco potenti...
e gli eseguibili win32?
hai provato?
un exe di win32 è un header con il codice (non ottimizzato) ed una
struttura a puntatori che contiene, una per una senza alcun tentativo di
ottimizzazione, le risorse utilizzate... bitmaps, dialog boxes,
cursori... tutto lì, un bit un pixel... se ci penso mi si spenge il
pc...
6 mega per un exe...
fantastico...
ciò che mi conforta è che anche sul lato unix le cose non sono
migliori...
-> GbC

in poco piu' di 500kB: anche qui, 5:1.
Un database di lavoro di 12 mega convertito in MySQL e' arrivato a 1.5
mega... E senza chiedere di comprimere la tabella.
Forse puntano alla velocita'.. se compattassi il testo e gli altri
dati avresti poi la necessita di scompattarli, consumando tempo e
risorse, e cio' puo' compromettere la velocita' di interrogazione e di
esecuzione del programma.
Guarda per esempio gli Information Retrieval, che al 90% dei casi
hanno il testo in chiaro, con un file di indice per le ricerche.

 un file?
Oltre a quanto detto da GbC io farei un distinguo: non puoi paragonare i
dati zippati a quelli non-zippati solo dalla dimensione.
Mi spiego meglio: se scrivi una lettera in plain text di 100k, zippati
diventeranno probabilmente meno di 10k.
Significa forse che la tua lettera è troppo prolissa e la si potrebbe
tagliare qua e là?
Non credo.
Inoltre se fosse così semplice i dati zippati dovrebbero essere ugualmente
"interpretabili", il che non è vero, poichè per comprimersi i dati hanno
bisogno di una "criptazione intrinseca".
Poi porti come esempio access :P che è famoso proprio per sprecare spazio :)
Access una un sistema di allocazione del disco a blocchi: i miei nuovi dati
non ci stanno nel file per 1 byte? Bene, mi alloco 1k.
Questo sistema ha dei vantaggi e degli svantaggi come tutti.
Il vantaggio principale è che per altri 1023 bytes non mi preoccupo più di
allocare spazio.
Lo svantaggio è che il file si gonfia più velocemente (come si è visto non
si preoccupa nemmeno di pulire la parte allocata, così può darsi che in un
mdb ti ritrovi parti di un documento privato se lo apri con Write).
Se poi aggiungi che access non si preoccupa nemmeno di ricoprire i record
cancellati con quelli nuovi, ma li accoda semplicemente...
Comunque è vero: è un circolo vizioso.
Software non ottimizzato ti spinge a prendere macchine più potenti, e
macchine più potenti rendono inutili eventuali ottimizzazioni.
Ciao

 in un file?
Tralasciando ora i formati fatti realmente male, quella di lasciare
spazio inutile e sovrabbondante può essere una valida strategia per
evitare (o perlomeno per ridurre) la frammentazione del file system.
D'altra parte ormai il rapporto £/MB su HD è decisamente basso.
Per quanto riguarda Access, credo rientri tra i primi che ho citato
(formati fatti realmente male), ma non credo sia lo stesso per Word (che
ha un formato abbastanza complesso) e per Excel (che mi pare un prodotto
valido).
Ciao.

"H.P.L." <u...@vaila.ble> ha scritto

senza voler difendere access, ho sempre supposto ci fosse un obiettivo
prestazionale. quando si fa un addnew con 100 campi txt di 255, mettendo in
ognuno un solo byte, lui comunque alloca lo spazio come se i campi fossero
pieni. al primo pack, riduce un bel po'. prob questo sistema, specie con
aggiunte massicce, riduce un po' i tempi.
questo col 97, non so col 2k e unicode. certo, anche compattato: un mdb di
28.1 viene portato a +- 10.5 sia da zipmagic sia da powerarchiver...
l'occupazione 'a vuoto' e' pero' un discorso molto relativo. anche un bmp o
un tiff possono essere compressi in zip. nt puo' comprimere le cartelle, e
zipmagic anche, pur lasciando lavorare al loro interno. il discorso era
valido soprattutto, e lo e' ancora in parte, con la fat16 e i dischi >2g, in
cui un bottoncino gif di 150 byte si prendeva 32k. ora se ne prende 'solo'
4.
mi e' comunque sempre sembrato piu' indegno il formato di word, che si
alloca spazio ogni volta come pare a lui, per giunta mettendoci dentro pezzi
di documento presi a caso, il che potrebbe piacere pochissimo a chi si
affanna a fare dei wipedisk. se si salvo 5 volte lo stesso documento,
aggiungendo ogni volta un solo byte, si hanno escursioni notevoli nelle
dimensioni. questo usando sempre la stessa versione. le prove le avevo fatte
a suo tempo col 97. francamente, se uno spreco ci deve essere preferisco
qualcosa di prevedibile a qualcosa di imprevidibile, anche se a volte
ottimizzato. cosa che peraltro, con word, succede poco.
ciao, j.

migliori...
Oddio, dipende da cosa si parla.
Per gli applicativi commerciali "di uso comune" la siguazione sta
peggiorando drammaticamente --vedi i Cad, ad esempio--.


hanno il testo in chiaro, con un file di indice per le ricerche.
Che e' sempre una buona scelta, salvo riuscire ad avere dei buoni
files di indicizzazione.


valido).
Beh, sulle funzionalita' di Excel si potrebbe parlare a lungo --ad
esempio, la formattazione dei grafici...--, comunque funziona bene
anche se salva malino =)


macchine più potenti rendono inutili eventuali ottimizzazioni.
Vero. Il trucco sta nel riuscire a sfruttare i programmi che si hanno
al 105%. Peccato che questo richieda tempo ed impegno. E voglia di
farlo...


 Gia'... Altro sigh che mi viene spontaneo...
non _puo'_ farlo. potrebbe, forse, con un record fisso tipo dbf, ma se lo
facesse dopo un pack mezzo record coprirebbe quello cancellato e mezzo
andrebbe in coda. non puo' ogni volta stare a guardare quanto spazio si e'
liberato in mezzo.

liberato in mezzo.
All'interno della stessa tabella, potrebbe e dovrebbe farlo.
Se crei 20 record, poi ne cancelli 10 e ne inserisci altri 10, lo
spazio occupato e' quello di 30 e non di 20.
A lungo andare --ma poi non cosi' a lungo--, lo spazio occupato
inutilmente diventa una cifra...
Naturalmente, sono d'accordo che lo spazio recuperato cancellando
record da una tabella ben difficilmente potrebbe essere occupato da
record di un'altra tabella --a meno di non fare un po' di conticini
per vedere di tappare qualche buco--.


 All'interno della stessa tabella, potrebbe e dovrebbe farlo.
stai parlando di una panda. anche in autostrada continua a essere una panda.
la valutazione di un prodotto non puo' essere strettamente tecnica. se
access fosse concepito come (saggiamente) vorresti, mi sa si chiamerebbe
sqlserver o oracle o...

 piazzati qua e la' nei 3 o 4 mb di files che rimani alla fine.
Purtroppo Word è un po' subdolo.
Bisogna stare molto attenti.
Una volta stavo inpazzendo per capire perchè lo stesso documento stampato da
un PC dasse il risultato corretto, mentre da un altro stampava pagine in
più, frasi inesistenti o pezzi cancellati da un pezzo.
Poi mi hanno rivelato che Word ha un'opzione ben nascosta per poter tener
traccia di tutte (ripeto "tutte") le modifiche apportate al documento.
E un'altra opzione che ti permette di visualizzarle o meno.
Questo spiegherebbe i tuoi problemi.
Altre verifiche sullo spazio usato da Word non ne ho fatte.
Ciao

 tentino di risolvere qualcosa... Boh...
Non ti viene il dubbio che industrie HW e SW facciano comunella?
Il circolo vizioso conviene a tutt'e due!
Ciao

 esecuzione del programma.
Anche questa mi sembra una buona mossa commerciale.
Ti dicono "uuuuh, guarda com'è veloce Access" (con una tabella vuota e DB
compattato).
Davvero veloce!
Peccato che tutti sanno come, quando access si gonfia un po' perde di
velocità.
Peccato che dopo un po' se non lo compatti si scassa e non  raro che la
ricostruzione non funziona.
Semplicemente spostano il problema dalla casa madre a te che commercializzi
prodotti basati su Access (il tuo cliente non telefonerà mai a M$ per
lamentarsi che si è perso lo storico delle fatture degli ultimi 10 anni,
sappiamo bene invece contro chi sbraiterà).
Furboni :(
Ciao

sappiamo bene invece contro chi sbraiterà).
Be',  il cliente va in formato prima. Se vuole fare le corse con una Panda
sono un po' cavoli suoi.
Altrimenti sceglie un database adatto a quello che vuole fare. 
-- 
ciao, hal

 Be',  il cliente va in formato prima.
cliente.prima ?
^__^

javalab ha scritto:

ROTFL
(non ti scappa proprio nulla :-)
-- 
ciao, hal

 tanto bene...
Ho già fatto dei test, anni fa. La misteriosa "compressione mista" di 
CPT 7 (NON CDR, che è per i disegni vettoriali) si mangia(va) senza 
problemi la RLE (LOL!) di PSD, e qualsiasi dei tre metodi di 
compressione applicabili ai PSP
Sul versante "compressione senza perdita di dati" vinceva CPT 7 tra i 
formati proprietari, e PNG tra quelli pubblici
Sulla compressione lossy (nel mio test avevo provato anche la 
compressione video: MPEG, colori e scala di grigi, e tutti i codec AVI 
di cui disponevo) stravinceva di diverse lunghezze il semisconosciuto 
Wavelet (estensione .WL), a qualsiasi grado di compressione (minimo, 
medio e massimo), persino sul JPEG ottimizzato. Ricordo che l'immagine 
di prova (il rendering di una superficie metallica con sfumatura di luce 
e trama a "diamante", 400x400 pixel - non esattamente il massimo per 
testare la compressione delle immagini, ma all'epoca non lo sapevo), al 
100% della compressione Wavelet, diventava un file da 700 byte, ancora 
discretamente intellegibile (la texture completamente distrutta, ma la 
sfumatura di colore era ancora riconoscibilissima); soprattutto non 
soffriva di effetti collaterali tipici di JPEG, come il tassellamento e 
la corruzione dei colori (credo perchè JPEG considera le immagini come 
mappe di byte, mentre Wavelet come bande di colore, o qualcosa del 
genere)
Avevo anche scritto un bel rapporto in formato testo, con tabelle 
comparative, annotazioni riguardo alle limitazioni di alcuni formati 
(avevo provato anche vecchissimi formati grafici di MacIntosh e Amiga: 1 
bit di profondità e persino limiti sulle dimensioni massime), e tutto il 
resto, ma credo di aver perso tutto nel Grande Disastro Di Norton 
DiskDoctor di qualche anno fa

 (non ti scappa proprio nulla :-)
la pipi'.
ora devi scusarmi, faccio un salto in parco...

 ha scritto nel messaggio
news:9s0hek$100m7r$1...@ID-51318.news.dfncis.de...

LOL
ciao
ugo

 Non ti viene il dubbio che industrie HW e SW facciano comunella?
Dubbio ? No, dico, _.-/*[DUBBIO]*\-._ ?
Un Paperino "...e le certezze come le chiami ?".



HA sbagliato a scrivere... intendeva dire che il cliente va formattato
prima :-)))

Il circolo vizioso conviene a tutt'e due!
Scusami, non mi sono spiegato. Io dicevo le industrie clienti, non
quelle produttrici. Naturalmente, chi produce ha interesse a che i
nuovi prodotti vengano acquistati. Io mi chiedo il motivo per cui i
clienti siano disposti a upgradare Office e Windows ogni anno e
spendere 2 milioni ogni pc. Tanto piu' che ogni anno e mezzo/2 anni
devono spendere anche 3 milioni per l'hardware...
Boh.


sqlserver o oracle o...
Sono d'accordo che recuperare lo spazio di altre tabelle sia
estremamente complesso e quindi su questo non discuto --anche se
PostgreSQL lo fa di suo e anche MySQL e' sufficientemente furbo da
farlo--. In ogni caso, recuperare con nuovi record lo spazio dei
vecchi record cancellati dalla stessa tabella non sarebbe niente di
che'.
Comunque, la soluzione al problema e' presto trovata perche' la mia
suite di applicazioni lavorera' su PgSQL, pero' si fa per parlare..


sappiamo bene invece contro chi sbraiterà).
Gia'... L'importante e' scaricare le colpe...
Tra l'altro si potrebbe parlare anche sul motivo per cui una software
house puo' farti firmare una dichiarazione di non responsabilita' sui
danni causati dai loro prodotti...
Considerando che per qualsiasi altro prodotto il produttore e'
--giustamente-- responsabile per qualsiasi tipo di danno :|


prima :-)))
Parole sante :-))))

 un'applicazione.
[cut]
sembra che almeno i file INI abbiano un barlume di efficienza in più, da
W2000... hanno tolto la riga vuota fra una sezione e l'altra  ;)
Faber

 4GB di ram per farlo girare :|
Dove lavoro ora ho raccontato di una mia disastrosa esperienza di
un'applicazione che lavorava su un DB access di 350MB con 6 PC concorrenti
(il DB su un server).
Mi hanno guardato un po' come se fossi un incapace, dicendomi che loro hanno
clienti con DB access che sfiorano il Giga con 20 o 30 PC in concorrenza.
Sul momento ci sono rimasto un po' male.
Ora mi sto rifacendo in silenzio sentendoli passare metà della loro giornata
al telefono spiegando come fare a ricostruire il DB da Access (fermando
tutte e 30 le macchine durante l'operazione e quindi la produzione :P)
Ciao

W2000... hanno tolto la riga vuota fra una sezione e l'altra  ;)
Peccato, solo, che gli .ini siano praticamente spariti :)
Saluti che io uso ancora i .ini =)


tutte e 30 le macchine durante l'operazione e quindi la produzione :P)
Hihihi :) Non so se posso dire "gli sta bene" =)
Considerando cosa gli costerebbe un pc con NetBSD+PgSQL... :)


 Peccato, solo, che gli .ini siano praticamente spariti :)
quindi niente piu' esigenze commerciali -> prob e' il motivo per cui adesso
possono migliorarli. fossero stati ancora molto in uso , li avrebbero
trasformati in xml o simili, con icone personalizzate ecc. :)

trasformati in xml o simili, con icone personalizzate ecc. :)
Effettivamente...
Pero' sento tanto la mancanza di quando aprivo con Edit.com in Win3.11
i files .ini per modificare qualche voce --perche' tipicamente
smanettando con le opzioni del sistema operativo lo inchiodavo-- :)
Saluti.


 smanettando con le opzioni del sistema operativo lo inchiodavo-- :)
ecco il tipico power user che poi fa i piedini ai gatti su 10 kb +- in un
file :))

 trasformati in xml o simili, con icone personalizzate ecc. :)
Allora, facciamo l'ipotesi che, qualche anno fa, avessero creato
un nuovo formato per i file .INI e avessero avvisato che:
- i dati di tutti i programmi sarebbero stati messi in un solo file
    o al massimo un paio
- le info avrebbero dovuto essere messe in formato gerarchico
    anzichč lineare, ma con le iconcine ;-)
- per memorizzare una stringa non sarebbe stato piů possibile
    farlo aprendo il file, ma solo smanettando con le funzioni API
- si sarebbe dovuto specificare ogni volta se si stava scrivendo
    una stringa, un valore binario o un esadecimale
- per accedere si sarebbe dovuto usare un programma fatto
    apposta anziché un qualunque editor standard di testo
- un qualunque utente o programma avrebbe potuto andare
    a scrivere quel che voleva, dove voleva o cancellare le info altrui
- le info di ogni programma sarebbero state messe nello stesso
    calderone insieme a quelle del sistema
- ogni prog avrebbe potuto disperdere le proprie info in N punti
    qualunque dell'albero gerarchico.
- per fare un backup delle impostazioni di un programma
    si sarebbe dovuto ricorrere a dei contorsionismi ignobili
- se si fosse rovinato quel singolo file ci si sarebbe giocato il
    funzionamento di tutto il PC...
Quante persone credete che lo avrebbero usato ?
Bene, ora chiederň un ultimo piccolo sforzo alla vostra immaginazione:
quale nome pensate che avrebbero usato, per questo sistema ?
Un Paperino che usa gli .INI, o dei file di testo.

Quante persone credete che lo avrebbero usato ?
suicide.ini? =)
Saluti.


file :))
Hahaha :) A dire la verita', io facevo i piedi alle mosche per 10
bytes :) Ma sono tempi andati... :P
Saluti che avevo fatto una rubrica in Pascal con alberi binari
bilanciati anche in cancellazione per andare piu' forte sul 386sx12 =)


 suicide.ini? =)
suicide.reg, piuttosto...   <g>
Faber

 suicide.reg, piuttosto...   <g>
Gią. E nonostante tutto questo, lo stiamo usando.
Un Paperino che:
C:\Windows>ren Regedit.* Suicide_ini_edit.*

 PC...
Questo pure.
Ciao.

 writes:
GR> A guardare quanto si zippano i files di Access mi rendo conto di
GR> quanto puo' essere fatto male un formato di salvataggio di
GR> un'applicazione.
Aye Bugbarbeq :)
Access  ha  delle scusanti.   Tutti  i  DB  hanno delle  politiche  di
allocazione di  spazio extra (non  usato e quindi  molto comprimibile)
per  l'aumento  dell'efficenza  negli  update. Access  non  ti  lascia
controllare  la  cosa  altri  si,  così per  le  tabelle  che  variano
lentamente lasci meno spazio.
-- 
Gian Uberto| main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Lauri      |                        David Korn, 1987 ioccc best one liner 
(aka saint)|-------------------------------------------------------------------
em@ail: 
sa...@eng.it
 ( vedere X-nospam nello header - see X-nospam in header )

suicide.reg, piuttosto...   <g>
Scusa, ma se fosse .reg e il registro non fosse stato inventato, dove
lo importavi? =)


lentamente lasci meno spazio.
Ecco, il solito Gian Uberto che viene a salvare i piu' deboli dagli
sfoghi post Guinness del cattivo di turno ;)


> lentamente lasci meno spazio.
GR> Ecco, il solito Gian Uberto che viene a salvare i piu' deboli dagli
GR> sfoghi post Guinness del cattivo di turno ;)
Ah, molto meglio le artigianali di microbirreria :) :) :) :)
Gian Uberto Lauri               "Bloody instructions which, being taught, 
sa...@eng.it
                     return to plague their inventor" 
C.so Stati Uniti 23              ("Macbeth", Atto 1, Scena 7; Hacker Jargon
Tel: 
+39 049 828 3556
             File 4.0.0, voce: Programming, 1)

> lentamente lasci meno spazio.
GR> Ecco, il solito Gian Uberto che viene a salvare i piu' deboli dagli
GR> sfoghi post Guinness del cattivo di turno ;)
Ah, molto meglio le artigianali di microbirreria :) :) :) :)
-- 
