| Author |
 Topic  |
|
wese
Leia
Italy
559 Posts |
 Posted - 19/01/2005 : 10:54:03
|
| il file è quello che si chiama Arch.sla |
 |
|
|
Simone
Cewbacca
Italy
88 Posts |
Posted - 19/01/2005 : 13:17:25
|
Magari Aldo!
Il file è quello arch.sla
la mia e-mail è parvadomus@jumpy.it
Ma tu di dove sei? il 29 e 30 noi facciamo una gara a Soriano nel Cimino(Viterbo)se stai in zona... |
|
|
|
chris
Obi Wan
Italy
2447 Posts |
Posted - 19/01/2005 : 14:56:28
|
privacy: non mi sembra molto vincolante, dato che la mia email è stata usata per altri scopi... ma questa è storia vecchia... In ogni caso,
Non capisco come possa un archivio di 30.000 nominativi (e quindi inclusi neonati, cugini e amici degli atleti veri e propri) possa diventare di 4-5 MB zippato... quello che serve è:
* nome (30 caratteri)
* cognome (30)
* CF (16)
* sigla della società (5)
* divisione/i (3)
* categoria/e (3)
il singolo record è di 87 byte (+2 terminatori), l'intero archivio è quindi meno di 2.700.000 byte, non compresso. Trattandosi di un file di testo, il rapporto di compresssione minimo è di 66%, quindi il file dovrebbe essere meno di 900 kB.
Se il db è strutturato bene anche meno...
Se poi il file di testo invece che essere "fixed field length" è un "Comma Separated Values" il tutto scende a meno della metà, che compresso diventa meno di 450 kB.
Non c'è la classe e il sesso, dato che sono deducibili dal CF... Programmando già sul Commodore 64, il risparmio era d'obbligo... Anzi, se proprio vogliamo risparmiare ancora, si può eliminare la divisione e lasciare solo le 3 categorie: risparmio di altri 90.000 bytes (circa mezzo minuto di download in condizioni critiche se zippato).
Oracle: A quanto so il DB è un MDB (access, quindi ancor più proprietario di oracle)... magari fosse oracle (anche se preferisco di gran lunga la velocità e stabilità del MySQL)
XML: non è tutto oro ciò che luccica! i file XML sono molto più "scritti" della loro controparte testuale o HTML, e questo rende a volte il file stesso piuttosto "pesante".
Alta velocità: non tutti abitano dove c'è l'alta velocità, e non tutti quelli che hanno un modem 56k si collegano a 56k... anzi, è molto più frequente di quanto si pensi collegarsi a 44k... oppure esserer a 52k ma su uno spezzone trafficato, e quindi scaricare a 1.1kB/s (significa passare circa 8 minuti per scaricare l'archivio da 450 kB)...
Aragorn il Prode (Chris)  |
Edited by - chris on 19/01/2005 15:10:21 |
|
|
|
anna
Luke
Italy
786 Posts |
Posted - 19/01/2005 : 15:29:14
|
Chris, non togliere le divisioni e le categorie... Come fanno gli arcieri che gareggiano in divisioni diverse con categorie diverse?
Anna
____________________
Niente acqua, niente luna |
|
|
|
Stef4o
Cewbacca
Italy
87 Posts |
Posted - 19/01/2005 : 15:38:11
|
quote:
Originally posted by chris
Non capisco come possa un archivio di 30.000 nominativi (e quindi inclusi neonati, cugini e amici degli atleti veri e propri) possa diventare di 4-5 MB zippato... quello che serve è:
* nome (30 caratteri)
* cognome (30)
* CF (16)
* sigla della società (5)
* divisione/i (3)
* categoria/e (3)
il singolo record è di 87 byte (+2 terminatori), l'intero archivio è quindi meno di 2.700.000 byte, non compresso. Trattandosi di un file di testo, il rapporto di compresssione minimo è di 66%, quindi il file dovrebbe essere meno di 900 kB.
Se il db è strutturato bene anche meno...
Se poi il file di testo invece che essere "fixed field length" è un "Comma Separated Values" il tutto scende a meno della metà, che compresso diventa meno di 450 kB.
Non c'è la classe e il sesso, dato che sono deducibili dal CF... Programmando già sul Commodore 64, il risparmio era d'obbligo... Anzi, se proprio vogliamo risparmiare ancora, si può eliminare la divisione e lasciare solo le 3 categorie: risparmio di altri 90.000 bytes (circa mezzo minuto di download in condizioni critiche se zippato).
Oracle: A quanto so il DB è un MDB (access, quindi ancor più proprietario di oracle)... magari fosse oracle (anche se preferisco di gran lunga la velocità e stabilità del MySQL)
XML: non è tutto oro ciò che luccica! i file XML sono molto più "scritti" della loro controparte testuale o HTML, e questo rende a volte il file stesso piuttosto "pesante".
Alta velocità: non tutti abitano dove c'è l'alta velocità, e non tutti quelli che hanno un modem 56k si collegano a 56k... anzi, è molto più frequente di quanto si pensi collegarsi a 44k... oppure esserer a 52k ma su uno spezzone trafficato, e quindi scaricare a 1.1kB/s (significa passare circa 8 minuti per scaricare l'archivio da 450 kB)...
Aragorn il Prode (Chris)
Premetto che non ho avuto né tempo né voglia di fare un po' di sano hackeraggio sul file archivio dell'ultima versione di SL... ricordo soltanto la versione 3.10 realizzata in Turbo Pascal 5.5 e la struttura del file. Il Pascal non usa il terminatore di stringa (come il C) ma antepone alla stringa stessa la sua lunghezza in un byte.
Chris, nel computo hai dimenticato che serve la corrispondenza tra il codice di società e la descrizione, altro spazio quindi... e magari la codifica di testo non è ASCII ma forse UNICODE, giusto per scrivere correttamente anche i nomi degli atleti stranieri  (ho detto: magari ) Metti che ogni carattere si porti via 2 byte ed ecco il tutto raddoppiato di dimensione...
Nei frequenti "intoppi" del sito FITARCO, non saltava fuori un messaggio di errore tipo ODBC driver failed....oracle ? Magari era Access... Anch'io preferirei MySql, infatti lo uso sempre quando si richiede un DBMS... e per giunta è gratis! 
XML: sicuramente c'è molto più di quello che appare, vedi i vari tag di demilitazione dei campi, ma è "testo" e quindi zippabile. Come webmaster preferirei un file XML, alla pagina HTML che sputa l'ASP del sito FITARCO, così potrei adattare lo stile del mio sito ai dati "ufficiali", senza impazzire inutilmente... non sarà l'oro, ma va bene anche la pirite 
Alta velocità: se il servizio di aggiornamento fosse realizzato dalla FITARCO medesima, non saresti obbligato a scaricarti l'intero archivio, ma soltanto i record (gli atleti) che ti servono. Quanti sono ogni gara, 200, 300? la centesima parte dell'intero archivio, suppongo. Come già hanno permesso ai presidenti di accedere ai dati sul server (quello vero, con i dati sensibili!) mediante password, così non vedo particolari problemi a consentire l'accesso ai dati per aggiornare l'archivio SL della gara di calendario. O no?
Stefano |
|
|
|
chris
Obi Wan
Italy
2447 Posts |
Posted - 19/01/2005 : 17:03:10
|
anna: i 3 byte di categoria erano appunto uno per ogni divisione: si chiama inferenza sulla codifica!!!
per quanto riguarda l'unicode non credo che il gioco valga la candela: quanti sono gli arcieri con caratteri non "West Europe" (tabella 850 oppure Latin-1)? se sono la metà degli arcieri vale la pena usare l'unicode, sennò no!
la trascrizione tra codice società e descrizione società è in un file a parte, ovviamente... non cambiano così di frequente e soprattutto non sono essenziali (basta il codice società!!!)
Per "passare" il file da archivio centrale a periferia bisogna passare i dati "mutevoli", non le costanti. Quindi sarà poi SL che codificherà l'archivio .sla "standard" dai dati recuperati dal sito centrale...
Aragorn il Prode (Chris) |
|
|
|
aldo
Leia
Italy
387 Posts |
Posted - 19/01/2005 : 17:03:55
|
Simone, sono di Aprilia Lt. arcieri le Rondini.
purtroppo la Tua gara coincide con l'Assemblea Elettiva ed ho una sola possibilità.
questa sera ti farò avere il file.
alla prossima.
Alo |
|
|
|
Simone
Cewbacca
Italy
88 Posts |
Posted - 19/01/2005 : 19:59:43
|
Ti ringrazio anticipatamente Aldo,mi dispiace che tu non possa venire..
Comunque noi siamo li,se qualcuno dei vostri vuol partecipare sarà il benvenuto!
PS
Il file invialo al mio indirizzo (parvadomus@jumpy.it) e non a quello che ho scritto sopra per le iscrizioni,se l'hai gia inviato fa lo stesso.. |
|
|
|
Topic |
|
|
|
scambio archivio e archivio generale
