Topic: Suggerimenti per database per pochi utenti  (Letto 93 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline Aaoograha

  • python unicellularis
  • *
  • Post: 3
  • Punti reputazione: 0
    • Mostra profilo
Suggerimenti per database per pochi utenti
« il: Novembre 01, 2018, 19:36 »
Buongiorno, chiedo aiuto e delucidazioni (e sberloni) perchè ho cercato di darmi una risposta da sola ma adesso ho in testa un marasma.

Devo realizzare per una scuola elementare un sistema di gestione prestiti biblioteca (devo=volontariamente).
Per vari motivi i vari applicativi già pronti non vanno bene.
Attualmente è in uso un database Access, vecchio di 15 anni ma piuttosto buono, da me risistemato l'anno scorso. Il problema è che chi l'utilizza lo trova poco "smart" , nonostante un'interfaccia molto semplice, pulita e automatizzata.
Credo che il problema derivi dalle abitudini derivate dal web e dagli smartphone.
L'utilizzo per ora avviene tramite portatile e non è in rete (rete che penso essere pressochè inutilizzata), ma in futuro ci potrebbe essere la necessità di utilizzarlo con tablet.

Allora, dopo aver realizzato alcuni script in python per recuperare i dati dall'Opac tramite ISBN e per migrare il catalogo già presente in Access, mi sono messa al lavoro con Django e Sqlite, pensando fosse la soluzione migliore, e i risultati riguardo al catalogo testi non sono male.
Adesso peró mi pongo due grossi problemi.

Il primo è di produttività: ci sto mettendo troppo tempo e credo che mi sia imbarcata nella reinvenzione dell'acqua calda!
Forse Django è titanico, e facevo meglio a trovare qualcosa di più snello. Forse mi occorre un CSM.
MA, tra le tremila opzioni mi sono veramente persa. Non ho problemi a reiniziare, ma non posso andare totalmente alla cieca.

Il secondo problema è più radicale. Sto seguendo la strada più sensata, pensando al web?
Ma soprattutto, visto le scarse competenze presenti nell'organico scolastico, non sto cercando di produrre qualcosa che poi li metterà in difficoltà?
E allora quali altre strade ho davanti (magari non buttando il file di database)? Anche qui mi sono persa...

Ok, sono stata verbosa, ma ho cercato di dare un quadro completo.
Spero che qualcuno possa fornirmi suggerimenti!

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.821
  • Punti reputazione: 9
    • Mostra profilo
Re:Suggerimenti per database per pochi utenti
« Risposta #1 il: Novembre 01, 2018, 22:14 »
Uhm guarda, mettiamola così. Dal punto di vista di ciò che può capire un utente, tieni presente che Access è un prodotto di vertiginosa qualità. E' stato inventato, ai vecchi tempi, da alcune delle menti più geniali che si siano mai applicate al problema di progettare interfacce grafiche, ed è veramente ma veramente improbabile che tu possa battere in qualità (in tempi medio-lunghi) un'interfaccia costruita con Access. A patto di averla costruita in modo decente, si capisce. Dove Access mostra tutti i suoi limiti è nel back-office, a partire da un database (Jet) molto scarso. Ma per piccole applicazioni da usare in pochi utenti, anche questo alla fine è un problema un po' secondario.
Ora, che i tuoi utenti trovino il sistema attuale "poco smart"... mi lascia un pochino senza fiato. Voglio dire, è la biblioteca di una scuola elementare, ma che esigenze ci potranno mai essere? Usarlo con un tablet? Usarlo in rete? Stra-caspita! Cioè, ma che cosa è questa biblioteca? Quanto potrà mai essere grande? E' distribuita su più plessi scolastici? Se ne occupa più di un insegnante?
Onestamente ti direi di prendere carta e penna e fare un elenco ragionato di tutte le cose che gli utenti attuali trovano... poco smart, come dici tu, e che cosa vorrebbero migliorare davvero. Quali sono i casi d'uso concreti che adesso non sono coperti. Se posso permettermi, ho il sospetto che il novanta per cento di quello che raccoglierai saranno dei vezzi un po' inutili. Cerca di capire che cosa manca davvero (ma davvero-davvero, non nelle fantasie di potenza degli utenti). E poi decidi se quello che manca non potrebbe essere aggiunto in Access.

Devi capire che il "rischio" che corri è di alzare le aspettative degli utenti (tablet come se piovesse! web!) e poi consegnare un programma magari pieno di piccoli bachi e problemi che saltano fuori di continuo, dovuti al fatto che magari adesso Access si prende cura automaticamente di un sacco di cose che invece dovresti farti a mano. Dico "rischio" tra virgolette perché ovviamente tutto questo non ti viene pagato, quindi alla fine tutto è relativo. Ma insomma, ci siamo capiti.

Per quanto riguarda "il web" (e Django, visto che è quello che stai vedendo). Ok, vada pure per "il web" se vuoi, però devi capire che "il web" comporta qualche pezzo che va oltre quello che adesso stai smanettando in Django sul tuo computer in locale. Perché ci sia "il web" ci deve essere un server web. E perché ci sia un server web deve esserci una macchina adibita a server di rete dove far girare il server web. E un amministratore che ti lascia fare tutto questo. Ora, se l'amministratore della rete sa il fatto suo e ti fa trovare già pronto tutto il necessario, perfetto: non ti resta che fare il deploy della tua web app (ossia in pratica del codice Django che stai scrivendo) sulla macchina server, e sei a posto. Viceversa, devi configurarti il server web sulla macchina, e alcune altre cosette. Non ci vuole una laurea in fisica (specialmente per la infranet di una scuola elementare, suppongo) però bisogna sapere un po' dove mettere le mani.

Per quanto riguarda Django (e i CMS): in python non ci sono "CMS". Se ti serve un CMS web, ci sono prodotti validi in giro. Il problema è che tu stai facendo un'applicazione specializzata, quindi anche i CMS "generici" non ti aiuterebbero comunque (per dire, non è che puoi usare joomla o wordpress per fare una cosa del genere, no?). O ti cerchi un CMS specializzato (come questo https://codecanyon.net/item/library-cms-powerful-book-management-system/21105281 ma ce ne sono parecchi), oppure resti con Access (che è effettivamente un po' un CMS). Poi naturalmente intendiamoci: un CMS che sta sul web deve comunque avere alle spalle un server web ed essere installato sul server di rete... stessi problemi di prima.
In tutto questo, Django è sicuramente un po' gigantesco, ma nel tuo caso non dovrebbe essere un grave impedimento. Per le cose semplici (come la tua) Django non si intromette in modo particolare. Se vuoi puoi provare con Flask che è più snello, ma non credo che alla fine della giornata risparmi molto tempo. La verità è che devi comunque scrivere tutto il codice delle view, dei form  e (soprattutto, la cosa che fa perdere più tempo) dei templates.

Per quanto riguarda "quali altre strade", ovviamente hai la possibilità di restare su Access mono-utente (come adesso). Io sicuramente starei su questa. Oppure (e sarebbe la seconda mia scelta) restare su Access e rendere l'applicazione multi-utente: questo migliora un po' le cose e hai il vantaggio che non sei ancora "nel web" (nel senso che non devi installare un server web, devi solo condividere una risorsa Access sul server di rete). Oppure (la mia terza scelta, con distacco) farti una GUI desktop in python (per esempio con wxPython o PyQt). Questo può essere multi-utente quanto vuoi, e ancora non hai bisogno di toccare la macchina server (se non per metterci il file del database sqlite). Naturalmente, anche così, niente "tablet" (perché questi gui framework funzionano solo sul desktop). E quindi, a parte il piacere di imparare ptyhon e le gui python, non si capisce perché non restare con Access.

Offline Aaoograha

  • python unicellularis
  • *
  • Post: 3
  • Punti reputazione: 0
    • Mostra profilo
Re:Suggerimenti per database per pochi utenti
« Risposta #2 il: Novembre 02, 2018, 17:54 »
Molti spunti di riflessione, grazie.
Ok, vada pure per "il web" se vuoi, però devi capire che "il web" comporta qualche pezzo che va oltre quello che adesso stai smanettando in Django sul tuo computer in locale.
Questo, e quello che ne consegue, era già nella mia testa, ma mi stavo chiedendo se per caso non riuscivo a vedere una via meno "complessa" e quindi più adatta. Mi confermi che non è così e che di conseguenza non è stata una buona scelta (amen, bello comunque aver appreso cose).
Ora, che i tuoi utenti trovino il sistema attuale "poco smart"... mi lascia un pochino senza fiato. Voglio dire, è la biblioteca di una scuola elementare, ma che esigenze ci potranno mai essere? Usarlo con un tablet? Usarlo in rete?...
Mah, alla fine penso che la forma mentis faccia la differenza.
Adesso hanno a disposizione un'interfaccia semplicissima, pulita e anche graziosa (!), non devono fare quasi nulla xchè è tutto predisposto per lavorare in automatico, peró è un'interfaccia differente da quella a cui sono abituate cotidianamente.
Del resto vanno in panico se su word cambia il set di icone, sicchè...
E posso capire che l'utilizzo con il tablet risulti semplificativo, proprio fisicamente intendo.
non si capisce perché non restare con Access
Access ha effettivamente tanti pregi.
Ma, devo andare OT, banalmente, è a pagamento. La scuola ha la licenza (per puro caso, diciamo così) per il solo portatile. E quando questo portatile va in vacca?
Apriti cielo...
E, altro OT, la retrocompatibilità non è il massimo. Il database originario è di 15 anni fa, utilizzato in un'altra scuola del comprensorio. Quando poi lo hanno messo da loro era un continuo aprirsi di popup allarmistici e di routine che non funzionavano. E così mi hanno chiesto di "dargli un occhio". Fatto, sistemato, adattato alla diversa organizzazione di questa biblioteca, cambiata interfaccia grafica, predisposti nuovi report, fatto manuale d'uso...
Ma di fondo rimane vecchio, con alcuni pezzi che alla prossima relise smetteranno di funzionare.

Rivederlo tutto? Con access basic? Mi viene male... (e comunque non posseggo una licenza access recentissima...)
Oppure (la mia terza scelta, con distacco) farti una GUI desktop in python (per esempio con wxPython o PyQt). Questo può essere multi-utente quanto vuoi, e ancora non hai bisogno di toccare la macchina server (se non per metterci il file del database sqlite). Naturalmente, anche così, niente "tablet" (perché questi gui framework funzionano solo sul desktop).
Ecco, speravo di non dover reinventare la ruota...
Comunque, magari, un occhio ce lo butto, vedi mai.

Quindi, ne deduco, la speranza di avvalermi di python non è molto realistica.
Perchè altre vie per database multidevice ne ho trovate, ma non compatibili con scrip python.
O sto mal interpretando la tua analisi?

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.821
  • Punti reputazione: 9
    • Mostra profilo
Re:Suggerimenti per database per pochi utenti
« Risposta #3 il: Novembre 02, 2018, 19:17 »
> Quindi, ne deduco, la speranza di avvalermi di python non è molto realistica.
No no, ci mancherebbe. E' senz'altro *molto* realistica e praticabile. Quello che stai cercando di fare è una classica "CRUD application": è una cosa concettualmente semplice e fatta mille volte in python. Il problema, mi sembra, è il tuo livello di conoscenza attuale (non solo di python, ma proprio della struttura generale di questo tipo di applicazioni). E di conseguenza il tempo che ti ci vorrebbe per "superare" l'attuale software in Access, partendo da quello che sai adesso. E l'altro problema è se *davvero* il tuo use case ha proprio *bisogno* di superare l'attuale sistema che tutto sommato funziona.
Mettiamola così: se fosse una questione di imparare Python poco per volta, poi imparare un po' di OOP, e poi un po' di gui framework e/o di web framework, e poi un po' di 3-tier architecture o qualcosa del genere, e poi naturalmente un po' di tecniche di sviluppo e manutenzione di un applicativo in produzione... e se tu ti volessi prendere un annetto tranquillo come esercizio per fare questa cosa... e se non ci fosse pressione dall'altra parte per avere certe feature, una certa user experience, supportare certi use case... Ecco, allora ti direi senz'altro di buttarti nell'impresa.
Ma se la tua idea è di consegnare un prodotto almeno equivalente all'attuale sistema in 3-4 mesi (o anche 6), allora francamente non credo che tu ci possa stare dentro. Oppure ho sbagliato di grosso a valutare il tuo punto di partenza, da quello che hai scritto.

> Mah, alla fine penso che la forma mentis faccia la differenza.
> ...
> E posso capire che l'utilizzo con il tablet risulti semplificativo,
Sì beh, certo... anche la mia vita sarebbe notevolmente semplificata da un milione di euro in banca e un paio di avvenenti massaggiatrici. Ma non è che possiamo basarci sulla "forma mentis" per prendere decisioni del genere, no? Cioè, vedi tu naturalmnte. Magari *vuoi* farlo come esercizio, ma allora comunque devi essere consapevole anche dei rischi. Nella mia esperienza, non c'è niente di più difficile di lavorare in amicizia per gli amici. Siccome non hanno un'uscita di denaro per misurare quello che ti chiedono in cambio, finisce paradossalmente che ti chiedono cento volte di più di un committente professionale.

 > Access  è a pagamento. E quando questo portatile va in vacca?
Uhm... non indaghiamo. Senz'altro "è gratis" è un ottimo argomento per usare Python e corollari. Ma per te non "è gratis", l'importante è capire questo.

> E la retrocompatibilità non è il massimo.
Scusa ma la retrocompatibilità di Access *è* il massimo, come tutti i prodotti Office. Storicamente MS si è sempre fatta in quattro e in otto proprio per garantire retrocompatibilità anche a lunga distanza. Se tu avessi voluto fare questa cosa 15 anni fa con Python avresti cominciato con la versione 2.3 e adesso saresti stata costretta a migrare tutto in Python 3, senza contare probabilmente un po' di piccoli problemucci lungo la strada (specie in windows). Se volevi farlo usando Sqlite, allora in Python 2.3 il modulo "sqlite" ancora non c'era: avresti dovuto scaricartelo come modulo separato. Sqlite stesso (il database) c'era già, ma ancora nella versione 2 che tra le altre cose non aveva il supporto Unicode (eh già). Se volevi farlo in Django, allora buona fortuna perché Django non c'era ancora. Se volevi farlo con una gui desktop, allora già c'era wxPython ma anche qui non giurerei sul supporto Unicode. Altrimenti c'erano le GTK e ti sarebbe andata molto peggio perché le GTK di 15 anni fa adesso sono deprecate. Altrimenti c'erano le Qt e ti sarebbe andata peggio ancora.
Tutto sommato non mi lamenterei proprio dei problemi di retrocompatibilità di Access su 15 anni di storia.

Offline Aaoograha

  • python unicellularis
  • *
  • Post: 3
  • Punti reputazione: 0
    • Mostra profilo
Re:Suggerimenti per database per pochi utenti
« Risposta #4 il: Novembre 02, 2018, 20:39 »
No no, mica mi lamento della retrocompatibilità di Access, mi sono espressa male.
Mettiamola così: se potessi fargli installare una versione più vecchia e mantenere quella sine die non starei a preoccuparmi...

Mi chiedo, ed è un po' la domanda di fondo: se è stato fatto mille volte, devo "per forza" ripercorrere tutta la strada dall'inizio? Cioè, quanto sarebbe utile veramente?
Non parto da zero, diciamo che dell'annetto che mi consigli di mettere in conto penso di avere alle spalle, metaforicamente, almeno sei mesi.
Poco comunque, a mio avviso, ma non zero, ecco.
E pur amando costruirmi le cose, ho la sensazione che perderei tempo un po' inutilmente.
Ma son cose su cui riflettere bene, sono d'accordo.

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 2.821
  • Punti reputazione: 9
    • Mostra profilo
Re:Suggerimenti per database per pochi utenti
« Risposta #5 il: Novembre 02, 2018, 22:36 »
> se potessi fargli installare una versione più vecchia e mantenere quella sine die non starei a preoccuparmi
Oh, sicuramente puoi farlo. Per assurdo, puoi farti una virtual machine con windows 7 (o anche win98 per quel che vale) e installarci un access del paleolitico se vuoi.

> se è stato fatto mille volte, devo "per forza" ripercorrere tutta la strada dall'inizio? Cioè, quanto sarebbe utile veramente?
Sì beh, anche andare da Milano a Roma è stato fatto già molte volte. Eppure un sacco di gente lo fa ancora: ogni volta che gli serve farlo. Naturalmente c'è poi la possibilità di farsi portare da qualcun altro, o mandare qualcun altro al posto tuo. Vedi un po' tu quel che puoi e vuoi fare.

> diciamo che dell'annetto che mi consigli di mettere in conto penso di avere alle spalle, metaforicamente, almeno sei mesi.
Uhm. Ok suppongo. Comunque le cose da capire sono quelle che ho detto. Nel tuo caso sei fortunata perché hai un modo infallibile per vedere se le hai capite. Se non le hai capite il tuo software sarà un incubo di bachi e i tuoi utenti torneranno rapidamente alla vecchia versione.

> ho la sensazione che perderei tempo un po' inutilmente.
Se il tuo scopo ultimo è imparare a programmare più di quanto tu sappia ora, sicuramente no. Se il tuo scopo ultimo è fare un sofware, beh forse in effetti sì, soprattutto quando hai una strada alternativa che mi sembra comunque abbastanza buona.