Consigli gestione abbonati - Foglio di Calcolo o altro?

[joe]

Ciao a tutti..
Problema: abbiamo una lista di abbonati ad una rivista locale.
Alcuni ritirano a amano, altri spedita quindi vi sono due differenti tipi di abbonamenti.

Dovrei sistemare "in divenire" questa lista, in modo da annotare a chi è già stata consegnata, a chi è stata spedita, chi ha rinnovato l'abbonamento ecc ecc.
Ad ognuno vorrei aggiungere anche una nota identificativa, sarebbe utile perché la maggior parte degli abbonati sono persone conosciute di persona, mentre altri sono "parenti di..." o similari, e dal nome spesso non si capisce bene chi sono e come fare a consegnare loro la rivista.
Ognuno poi dovrà essere associato al proprio gruppo di distribuzione, infatti per le consegne a mano ci si appoggia a tot volontari che coprono un certo gruppo di abbonati sia in base alla zona che in base a parentela o occasione di incontro. del tipo tizio distribuisce a caio la sua rivista e quella di sempronio, in quanto lavorano insieme e ha modo di vederlo per dargliela...
Capite bene che è una roba molto alla buona... comque funziona bene nella pratica e si distribuisce un po' l'impegno su più persone rendendolo meno gravoso.

Al momento organizziamo questa lista a partire da un foglio di calcolo con libre-office calc.
Che potrebbe anche andare bene, ma mi chiedevo se non ci fosse qualcosa di meglio.

Ad esempio io vorrei fare un'interrogazione ed ottenere la lista di tutti gli abbonati che hanno già pagato il rinnovo ma non gli è ancora stata consegnata.
Oppure ottenere la lista degli abbonati a cui sono è già stata spedita la copia, ma che non ha ancora rinnovato l'abbonamento.
Capite bene che più sono i "parametri" che caratterizzano gli abbonati più possibilità di fare interrogazioni ci sono.

Ora, personalmente non sono un drago coi fogli di calcolo, li uso poco ecc...
Ma così al volo per una cosa del genere avreste in mente un metodo migliore per gestire questa roba?

Grazie in anticipo!

PS.
Al momento mi occupo della cosa affiancato da collaboratori amanuensi cui stampo la lista e annotano tutto a penna sul retro.
Potenti mezzi, ma quando ci si deve metter emano dopo mesi, si fa un po' fatica a raccapezzarcisi !

[cressida]

Un piccolo database?

[joe]

È quello che pensavo anch'io, ma dei DB ho qualche svanito ricordo di un corso Access risalente alla notte dei tempi e servito poi come l'ombrello nel tifone, e pertanto dimenticato e rimosso. Diciamo pure che non ne so nulla.
Questo non significa che non sia disposto a leggermi qualcosa.
Se hai qualche idea o link per approcciare l'argomento, "progettare" un attimo l'eventuale DB e infine tramutarlo in qualcosa di pratico/applicativo te ne sarei grato.
Su questo ultimo punto sarebbe anche utile un consiglio su quale strumenti usare, cioè a quali programmi fare riferimento.

[brg]

Se fai un corso di basi di dati, probabilmente come esempio applicativo elementare ti tirano fuori un caso come il tuo.

Anni fa feci una applicazione con PHP e MySQL per una piccola biblioteca: è ancora in funzione. A seconda di quanto è grande la lista degli abbonati, potrebbe bastare anche un semplice programma che salva i dati in un formato accessibile, tipo CSV o XML. Linguaggi come Perl o Scala potrebbero fare al caso tuo a seconda delle esigenze.

Io i fogli di calcolo sinceramente li lascerei solo per fare la lista della spesa.

[joe]

Ah beh è una tiratura abbastanza ridicola come numero totale, parliamo di tipo 300 abbonati... O giù di lì.
Il fatto che sia un caso da manuale mi incuriosisce sul discorso basi di dati, più che altro perché, impara l'arte e...

I fogli di calcolo in questo specifico caso, non sono del tutto da buttare, alla fine gestisco la cosa da anni così, ma l'unica funzione che ero riuscito a sfruttare era l'ordinamento in base al "distributore incaricato", in quel modo mi ritrovavo la lista con i vari gruppetti di consegne già raggruppate altrimenti la lista ufficiale è disposta in ordine alfabetico dell'abbonato. Una banalità, ma nella pratica si fa ovviamente molto più presto a preparare le consegne.
Probabilmente per la mia utilità ci si potrebbe accontentare di questa sola funzione, ma sono convinto che organizzando un po' meglio la gestione degli abbonati, ad ogni uscita si possa risparmiare tempo automatizzando qualche passaggio, qualche verifica ecc ecc...

Vedila così, adesso i dati essenziali sono salvati in file CSV (banalmente: nome, se abbonato con spedizione indirizzo, poi c'è il gruppo di consegna se ha consegna a mano ed eventuale sottogruppo di consegna, come spiegavo la gestione delle consegne è un attimo "capillare" con dei postini principali che in alcuni casi consegnano un pacchetto di riviste a dei distributori "sottoposti", i quali recapitano poi ai singoli abbonati).
File CSV quindi, ma il tutto è accompagnato da una marea di note appuntate spesso su foglietti svolazzanti che non mi piacciono per niente. Del tipo, tizio ha spedizione ma siccome era nei paraggi gli è stato consegnato a mano, Caio ha ricevuto la rivista ma non ha rinnovato abbonamento perché non aveva i soldi con sé, o ancora Tizio paga per Caio, ma a Caio deve essere spedito.... Insomma un gran garbuglio, che si districa in divenire, man mano che i vari abbonati hanno ricevuto la rivista e hanno rinnovato l'abbonamento. Altri dati utili da aggiungere al database, come accennavo all'inizio potrebbero essere delle note di identificazione dei vari abbonati, tipo chi diamine è mario rossi? dove abita quando è nei paraggi? Chi gli è vicino ecc ecc...
Tutte queste note si rincorrono ad ogni uscita del numero della rivista e se non si annota tutto è facile poi confondersi. Io banalmente faccio una directory per ogni uscita e dentro conservo vari files di note, alla fine funziona, ma in qualche occasione sono dovuto andare a cercare indietro... Insomma non è un sistema perfetto, né troppo automatico.

Da quanto ho detto vi sembra sovradimensionato fare un database propriamente detto?
È così complesso? Tanto da far preferire un programma ad hoc?

[gian_d]

Io penso che anche un numero piccolo come 300 abbonati sia già sufficiente per giustificare l'impiego di un database relazionale. Anche senza andare sul complicato, va benissimo per questo scopo LibreOffice Base. Peraltro se hai già avuto qualche esperienza con Access ancora meglio perché Base riproduce in sostanza la filosofia di Access. Il vantaggio rispetto ai database veri e propri è che non devi predisporre un'interfaccia grafica accessibile, che in genere richiede l'impostazione di un server web e di una piattaforma di script lato server. Insomma, comodo da usare in una workstation anche non connessa e portabile da una macchina ad un'altra con una pendrive.
Il foglio di calcolo è sicuramente la soluzione più semplice, ma alla lunga rivela tutti i suoi limiti nella gestione dinamica di dati.

[joe]

Ieri sera poi avevo trovato questa lista di video in cui spiega un po' di teoria applicata ad un caso piuttosto semplice che forse potrebbe assomigliare al mio:

https://www.youtube.com/watch?v=FnkL4Yd ... PbtQ-yycFH

Penso che indipendentemente poi dallo strumento con cui si va a realizzare nella pratica, un esempio del genere di progettazione sia concettuale che logica del database possa tornare molto utile.

Per quanto riguarda l'esperienza con access, risale davvero a troppi anni fa e fai conto che ricordo solo il colore simil rosso o rosa dell'icona di avvio del programma. Libreoffice potrebbe essere una scelta giusta con il suo Base, valuterò, ma ti dico la verità: con programmi della suite office ho sempre avuto più grattacapi che altro, il che mi ha sempre fatto propendere per soluzioni meno user-friendly.

[gian_d]

Io sono un maniaco dei database, iniziai con Access nella metà degli anni 90 per fare una piattaforma per gestire una biblioteca scolastica. In seguito, con l'uso nel web, sono passato a SQL Server. Ormai non uso più i prodotti Microsoft da oltre 10 anni, da quando mi sono finalmente deciso a usare MySQL e PHP.
Ma ripeto, per piccoli scopi il Base di LibreOffice è eccellente. Più spartano rispetto ad Access ma altrettanto funzionale e, peraltro, anche portabile. Se non hai esperienza puoi iniziare dalle tabelle: in sostanza è come "popolare" un foglio di calcolo, con la differenza che devi preimpostare il formato dei dati per ogni "campo".
In una seconda fase sfrutti le potenza dei database relazionali, quello che fa la differenza con i fogli di calcolo, ovvero collegare con le adeguate relazioni i dati di più tabelle.
Poi c'è il terzo aspetto, quello più importante per piattaforme come Access e LO Base, l'interfaccia grafica per la gestione dei dati: le tabelle dei "database" e i fogli di calcolo sono poco ergonomici, ma le finestre di Access e i formulari di Base ti consentono di accedere ai dati con semplicità. Oltre al fatto che si possono personalizzare, adesso anche su Base si possono creare le "autocomposizioni" ovvero la creazione automatica di un formulario basato su una o più tabelle.

Questo richiede un po' di lavoro all'inizio, ma il tempo speso è in realtà un investimento. Ad esempio, io uso Base per gestirmi tutti i pacchetti installati con gli slackbuild, oltre 200. In questo modo mantengo la traccia dello status di ogni pacchetto (dipendenze, versioni, note specifiche, categoria, ecc.). Avevo iniziato mettendo tutto in un foglio di calcolo, ma alla fine mi sono reso conto che era più complicato che andarmi a spulciare di volta in volta i vari file degli slackbuild (info, readme e slackbuild). Ma soprattutto, se devo aggiornare un qgis o vlc per citare degli esempi, per mezzo di questo database vedo subito anche le dipendenze che devo controllare.

[aschenaz]

Lo so, storcerete il muso, ma a volte alcune soluzioni sono sovradimensionate rispetto alle esigenze reali...

Se non vuoi scomodare un database (secondo me sempre e comunque consigliabile), puoi anche risolvere spartanamente ricorrendo ad un foglio elettronico condiviso, ad esempio su google drive...

[brg]

Per me la soluzione migliore sarebbe usare SQLite, che non ha bisogno di server e si può interfacciare con una infinità di linguaggi di programmazione, inclusi quelli interpretati come Perl o Python, e si può usare pure tramite un semplice script Bash. Poi se uno vuole fare un'interfaccia più avanzata, metterlo su un server o chissà cosa, può sempre farlo a tempo debito, tanto il file con l'archivio rimane quello.

[joe]

Ti dico la verità SQLite, mi incuriosisce molto. Ma allo stesso modo che un bimbo è incuriosito da qualcosa che suona bene anche senza sapere cosa diamine sia. Non so se ho reso l'idea dell'ignoranza in merito.

Devo premettere, riguardo ai fogli di calcolo, e rispondo ad aschenaz, che il foglio di calcolo è la via che abbiamo seguito fin qui. Prendilo come lo stato di fatto diciamo.
Ma i limiti sono evidenti: ad esempio gli abbonati dell'anno scorso se avevano rinnovato l'anno scorso mi servono solo fino a quest'anno, poi l'ipotetica colonna rinnovi 2019, così come quella "rinnovi 2018" ecc non mi serve più... A meno che qualcuno non abbia rinnovato per più anni, è possibile e in quel caso serve sapere fino a quando sono coperti dal rinnovo e gli va consegnata la rivista.

È solo un esempio, ma tanto per rendere l'idea.
Comunque posso anche lasciare tutto così com'è.
Magari c'è un po' più sbattimento quando si vuole tirar fuori delle liste di dati raggruppati con un certo criterio, ma pazienza. Non è mica escluso che alla fine non sia meno dispendioso rispetto ad imparare a creare un DB e gestirlo a distanza di mesi (che mica è così scontato che mi ricordi poi tutto dopo 3 o 4 mesi).

Didatticamente parlando ho seguito un'infarinatura dei video sulla progettazione database che ho linkato sopra, realizzata sul canale del tale "fcamuso". Lui faceva vedere appunto diversi esempi di applicazione del modello concettuale entità - associazioni ER. Come strumento grafico utilizza un programma apposito, RISE editor. Non so su linux quali equivalenti Freesoftware ci sono per lo scopo. Ad ogni modo penso sia una serie di video utili per capire di cosa stiamo parlando.
La parte dell'implementazione del "modello logico" che da quanto ho capito la spiega anche ma mi pare con altro programma... se non ricordo male MySQL Workbench. Ho visto tutto molto rapidamente ma tanto per orientarmi.

Comunque affronta parecchi argomenti tra cui la normalizzazione di casi mal progettati ecc...
Insomma devo rivederlo un attimo ma grosso modo la parte progettuale l'ho infarinata.

Tra parentesi tra le sue playlist ce n'è una sul python, che mi ripropongo di guardare.
Se SQLite supporta in qualche modo bash, quella un pochino la so maneggiare.

Ora stavo guardando qualche esempio di costruzione DB attraverso Base di LibreOffice. Sono sempre partito da video sul tubo, ma quello che ho visto adesso è un po' prolisso, sicuramente completo ma magari un po' troppo per quel poco che serve a me, ma forse è solo "colpa" del narratore che la tira un po' lunga e si perde un po' troppo in dettagli tipo dell'interfaccia o altri cavilli... Va be' a caval donato... Poi per carità sono sempre opere più che meritorie!

Bene comunque dalle vostre risposte direi che c'è tutto:
- restare ai fogli LO Calc
- provare a fare un database con LO Base
- buttarmi su SQLite

Ora sì che tutto chiarissimo!

[joe]

Siccome ho trovato degli spunti secondo me molto fatti bene, rapidi e applicativi per capire a grandi linee come si opera in una modalità diversa dai vari applicativi grafici, tipo LO-Base ma non solo metto qua sotto il link a questa playlist del canale di tale Paolo Aliverti:

https://www.youtube.com/watch?v=FMVAluE ... PVauREQnsl

In particolare sono inerenti all'argomento database le lezioni da 53 a 58 incluse.
In realtà ripensando all'altro link che avevo messo che trattava in modo più formale la teoria della progettazione database, queste qui non sono esaurienti, però danno bene l'idea di come si usa SQLite.
Quel canale è rivolto ad un utenza di cosiddetti makers, che non siano esperti né di elettronica né di programmazione. Ecco che il tizio ha messo insieme dei video molto interessanti veloci e dai quali passa

L'ultima lezione pur non conoscendo il linguaggio "Processing" mettono in luce la possibilità di gestire attraverso i comandi sql un database per mezzo di uno script. Ad intuito pensando al mio obiettivo, ovvero effettuare una modifica ad un nome o ad un indirizzo di consegna, oppure marcare come recapitata o spedita una certa consegna ecc ecc... Mi viene da pensare che banalmente si potrebbe predisporre uno script bash per eseguire compiti ricorrenti: modifica un certo campo di una tabella, oppure estrai gli abbonati ancora da consegnare con spedizione o quelli ancora da consegnare, magari ordinati in base all'incaricato di consegna ecc... o ancora visualizzare tutte le note per tot...
Mah non so eh... va a finire che le possibilità poi diventano anche troppe e alla fine tanto vale impararsi direttamente il SQL a memoria. No va be' scherzavo...
Effettivamente le potenzialità dello scripting bash associato ad un database relazionale messo in piedi in quel modo sono evidenti, soprattutto perché alcune operazioni vanno eseguite in modo ricorrente sempre uguali, ad esempio, stampa la lista degli abbonati che hanno già pagato il rinnovo ma a cui deve essere spedita la rivista. Questi abbonati vanno imbustati in un certo modo ad esempio ed è utilissimo che chi imbusta ne abbia una lista stampata.
Immagino che le stesse query ricorrenti siano salvabili in qualche modo anche in lobase o in access o altro marchingenio.

Premesso che mettere in piedi il piccolo databse in oggetto è una roba optional, credo che cercherò di prenderla come un'occasione d'apprendimento e proverò a realizzarlo usando strumenti differenti.

Venendo al pratico, siccome non ho la minima intenzione di popolare i campi delle tabelle ricopiando a mano e siccome ho già la mia lista abbonati in un foglio ods...
Come fareste voi per importarle in un database lobase?
E come fareste per importarle in un database SQLite?

Confesso di non aver cercato ancora in merito, sicuramente qualcosa si trova, ma probabilmente qualcuno qui avrà già avuto a che fare con l'operazione e saprà dirmi cosa gli pare più semplice.

[aschenaz]

Per importare da o per un foglio di calcolo o tra vari dbm, c'è il formato jolly csv (comma separated values): in pratica una sfilza di valori separati da virgole o altro...

[joe]

Ok, quindi in pratica per esempio: esporto il mio foglio .ods su un file in formato CSV.
Poi se si usa LO-Base immagino ci sia l'opzione per importarne una colonna e con quella popolare un campo di una tabella... O sbaglio? O magari c'è già la possibilità di importare in Base direttamente dal file .ods.

Invece con SQLite quindi dopo aver esportato il foglio in CSV praticamente come si fa a usarlo per importarne dati nel database?

[aschenaz]

Su LO Base basta aprire il file .csv (in genere ci sono delle opzioni sui campi separatori etc...).
Per SQLite (che ho testato in un remoto passato) ci sono i comandi SQL (che poi sono più o meno uguali, se non ricordo male, a quelli degli altri DBM) via terminale...
In ogni caso, in rete trovi le istruzioni.