[Python] migrazione da msaccess a python

Gio 30 Ago 2007 16:18:36 CEST

On Thu, 30 Aug 2007 15:41:15 +0200, Y3s <y3s a katamail.com> wrote:
> 
> Il giorno 30/ago/07, alle ore 15:17, Daniele Varrazzo ha scritto:
> 
>>
>>
>> On Thu, 30 Aug 2007 13:32:09 +0200, Y3s <y3s a katamail.com> wrote:
>>>
>>> Il giorno 30/ago/07, alle ore 13:03, Marco ha scritto:
>>>
>>>> Ciao sto anche io facendo un lavoro del genere per la mia azienda
>>>> ma non è affatto facile.
>>>> Per quanto access sia una schifezza, come dicono tanti,  permette
>>>> personalizzazioni molto veloci a livello di query o report.
>>>> Python al contrario ti permetterà sicuramente una maggiore  e una
>>>> migliore gestione a livello di linguaggio e di sicurezza dei dati,
>>>> indipendentemente se ti basi su mysql o altri.
>>>> Se però ti chiedono una qry al volo o un report  non ci metterei
>>>> senz'altro i 10 min che ci mettevi prima a crearlo dal  nulla.
>>>
>>> Non sono per niente d'accordo, anzi in python (avendo strutturato
>>> bene il tutto) è ancora più semplice. Apri il file (file di testo,
>>> che puoi aprire in situazioni di emergenza con notepad), scrivi la
>>> query, la associ al pulsante, menu o quello che è ed è fatto. Per i
>>> report, al momento in effetti strumenti comodi non ce ne sono ma
>>> idem, se hai creato un'infrastruttura ben fatta (ad esempio dei
>>> template per reportlab), non ci vorranno 10 minuti, ma in 15 hai
>>> fatto...ed è un lavoro molto più pulito e stabile direi!
>>
>> Tu come li fai i template in reportlab?
>>
> 
> Per "template" intendevo un "modello". In genere le tipologie di  
> report che si usano in un'applicazione sono poche. Una volta che hai  
> coperto in modo per te soddisfacente i casi che ti interessano, è  
> rapido e veloce modificare la classe, la funzione, o qualunque cosa  
> usi per generare l'output per adattarla al nuovo report.

Ok, quindi devi comunque scrivere codice per avere un template. Questo
rende i template non disponibili a chi non sa programmare.

>> Io ho avuto successo solo usando una versione patchottata di un  
>> parser RML
>> "bootleg" che trovai abbandonato da qualche parte nel web (per avere
>> RML2PDF devi comprare il "ReportLab Enterprise Publishing and  
>> Reporting
>> Server"... e il nome dice tutto su quanto te lo vogliono far  
>> pagare), e
>> anche allora quello che ho avuto è stato un linguaggio per fare *i
>> report*, non *i template*: questi ultimi me li sono fatti con  
>> Cheetah che
>> genera RML che genera PDF - un altro strato di roba da imparare.  
>> Alla fine
>> va, ma è veramente un hack che non me la sentirei di consigliare a  
>> cuor
>> leggero.
>>
>> Hai una soluzione più pulita di questa? Sarei felice di conoscerla. Se
>> no... direi che promettere a qualcuno che farà report "non in 10  
>> minuti ma
>> in 15 sì" mi sembra un po' grossa.
>>
> 
> Al momento no, ma ci sto lavorando. Purtroppo il tempo è sempre poco.
> C'è openreport (o comunuque si chiami, non ricordo, comunque quello  
> che usa tinyERP) che più o meno dovrebbe fare quello che fai tu, ma  
> in modo un po'più integrato.

E' *quello* il bootleg di rml2pdf che ho usato :) ed è quello che ho
dovuto integrare con un sistema di templating mio. Per la cronaca, la
homepage è andata, il progetto ritirato da freshmeat e se ne possono
trovare le macerie solo nella cache di google.

> Comunque, si parlava di "query al volo o report", quindi davo per  
> scontato che il grosso del lavoro sia già stato fatto. In tal caso,  
> non ci vuole molto ad adattare un report che già hai per creare  
> qualcosa di nuovo che, ripeto, nel 90% dei casi sarà molto simile  
> come struttura a uno che già hai. Inoltre, ho specificato che *avendo  
> strutturato bene l'applicazione* e *avendo creato un'infrastruttura  
> adeguata* la modifica al volo è un'operazione semplice e rapida,  
> certo partendo da zero il tempo necessario è maggiore...almeno  
> all'inizio, visto che molto del codice che vai a scrivere la prima  
> volta, lo riutilizzerai quasi sicuramente le volte successive...

Hai detto che mettendoci N mesi di lavoro, un template di scrive in 15
minuti. Con queste premesse sì, e aggiungo anche *avendo creato _bene_
l'infrastruttura*, ovvero avendo usato delle capacità di progettista e
sviuppatore al di sopra di quello che serve per progettare (zero) e
implementare (poco) un singolo template. Anche io posso andare sulla luna
in 3 giorni, *avendomi la NASA costruito un missile adeguato in 10 anni*.

>> Access è ottimale per una certa classe di applicazioni: se (e solo  
>> se) si
>> è ossequiosi verso il suo paradigma, consente di fare applicativi -  
>> male -
>> ma velocemente. In Python le cose si possono fare bene, si è liberi  
>> sul
>> paradigma di accesso ai dati, si possono fare anche certe cose
>> velocemente... ma non le stesse che si fanno con Access altrettanto
>> velocemente.
>>
> 
> Se l'obiettivo è avere un'applicazione che funziona in poco tempo, se  
> non si è interessati alla qualità del codice, se non ci si preoccupa  
> troppo della manutenzione e dell'espandibilità, se si vuole correre  
> il rischio che con la nuova versione dell'applicativo il tuo  
> programma non funzioni più, allora si, Access è un ottimo strumento.  
> Troppi se per i miei gusti, ma...
> Io continuo a pensare che una volta che ti sei costruito un insieme  
> di moduli adatti alle tue esigenze, sviluppare in python non è molto  
> più lento che farlo con access o altro. Il grosso del tempo lo perdi  
> solo una volta. Ovviamente è una mia opinione, eh!

Ovviamente ci sono molti "se" anche per me, per questo non tocco Access
neanche con un bastone (dopo averci sviluppato per un paio di anni e quindi
conoscendolo piuttosto bene). Però se ci sono persone che ritengono di
aver bisogno solo di quelle (ovviamente per una soluzione ad hoc per un
problema personale, non per creare un package da ridistribuire), non lo si
batte solo a parole. 

Il discorso è sempre "good, fast, cheap: pick 2": Access è veloce ed
"economico" (nel senso che uno Office ce l'ha, in un modo o nell'altro, e
comunque "lo deve avere" se non vuole essere tagliato fuori da certi giri
economici nei quali molti di noi provano piacere a non essere). Python è
"good e cheap" ma non così veloce come un bundle
database+linguaggio+report+ui tutto mischiato in uno e *giocando sul
terreno di quest'ultimo*. Sono anche io perfettamente conscio che con
Python ognuna di queste singole cose la si può fare meglio, e Python
comunque sarebbe la mia scelta (soprattutto per colpa della limitatezza dei
programmi realizzabili con Access), ma ne valuto bene il costo in termini
di tempo di sviluppo.

-- 
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com