Mi sto domandando come reagirei io a quanto da me scritto nel precedente post se fossi al posto di uno di voi due.
Probabilmente proverei un po di risentimento pensando “guarda un po questo bel tipo, gli metto a disposizione la mia esperienza e lui pretende di saperne più di me e mi sta pure a sfottere facendo il finto modesto, non rendendosi conto delle cavolate (direi cavolate? Davvero?) astronomiche che spara come verità fondamentali”. Penserei seriamente di lasciarlo andare al suo destino e abbandonare il progetto.
Sono contento che al vostro posto ci siate voi.
In effetti quello che ho scritto non mi piace, non che non dica quello che penso anzi, ma è mal esposto, insomma non è facile spiegare bene cosa vorrei riuscire a fare.
Il punto è, come già ho avuto modo di dire, che occorrerebbe semplicemente saperlo ma io non lo so.
O meglio lo so ma solo in parte, quella iniziale occorrerà che ve la esponga con più dovizia di particolari in modo da evitarci nuove incomprensioni.
Potremo così verificare se l'obiettivo è perseguibile oppure no.
Io non so cosa è effettivamente un gestionale ma ho la presunzione di credere di sapere teoricamente come si progetta un buon database.
La progettazione di un database prescinde il software sia di database che di programmazione.
Credo proprio che durante la progettazione non bisognerebbe mai porsi la domanda “già ma poi questo con Gambas e PosgreSQL come lo metto in pratica?”, trovo che sarebbe un errore.
Per ora non pensiamoci se non come ipotesi di studio come fare questo o quello nella pratica, magari la soluzione viene da se con la buona progettazione.
Io credo questo un database ben progettato poi lo si potrà mettere in pratica con qualunque strumento.
Detto questo entriamo un po più nel particolare e iniziamo a mettere qualche paletto:
Qui vi elenco pochi assiomi, regole che io giudico imprescindibili al buon funzionamento di un database relazionale.
Tabella:
Ha sempre una chiave primaria che ne garantisce l'integrità a livello di record, i suoi campi contengono un unico valore, non contiene campi calcolati, rappresenta un singolo oggetto o evento.
Campo:
È unico in tutto il database, è in relazione con gli altri campi della tabella rappresentandone una caratteristica, contiene un valore unico, vale a dire che tale informazione non può essere suddivisa in parti più piccole, non può contenere un valore calcolato.
Relazione:
L'integrità relazionale è data dalla corretta individuazione delle chiavi primarie e delle chiavi esterne, permette di inserire ed eliminare record senza effetti negativi.
Vista:
Per ottenere tutte le informazioni come i campi calcolati e i dati filtrati da più tabelle.
Naturalmente ci sono le eccezioni, i campi ridondati ma devono essere i meno possibile e solo dove strettamente necessario in quanto comportano una possibile fonte di errore.
È anche vero però che troppi join nuocciono alle query.
Lo so ne abbiamo già discusso e mi avete detto che nei vostri gestionali non è così.
Ciò non toglie che noi inizialmente nella fase progettuale ci atterremo a queste poche e semplici regole che non sono scolpite nella roccia ma sono solo di buonsenso.
È prematuro attualmente che non abbiamo ancora isolato i dati che dovremo raggruppare in relazioni per poter ottenere le informazioni utili al database già discutere di questo, questo per ora è il solco in cui ci muoveremo la stella polare su cui tracceremo la rotta poi al momento opportuno discuteremo e risolveremo.
La cosa è molto semplice al momento opportuno basterà dimostrare che un metodo o sistema è meglio di un altro per quel tale e talaltro motivo.
Non sono la vestale del campo perfetto basta convincermi con valide motivazioni. Ad esempio dirmi “nel mio gestionale non c'è” non è sufficiente.
Se anche a Sotema, Tornu e chiunque altro vorrà partecipare va bene la nomenclatura e la trova sufficiente possiamo passare a raggruppare questi benedetti dati.
Appena ho messo giù un esempio calzante e rappresentativo di quello che intendo lo posto così che possiate partecipare anche voi se vorrete con elenchi di dati o con suggerimenti e critiche costruttive.
La mia idea di questa fase era di tipo colloquiale cioè una immaginaria discussione fra noi e il cliente ma visto che non ha funzionato proviamo così.
Come ho già detto e ripetuto io di contabilità non ne so se qualcuno di voi è ferrato nel campo è pregato di postarne i dati utili e un po di spiegazioni. Tornu aveva proposto di non metterla nel progetto voi cosa ne dite? Io proverei se però ci si rende conto di non poter continuare si è sempre in tempo a fare marcia indietro.
Vi chiedo un po di pazienza proviamo a muoverci così e vediamo se diventiamo più produttivi.
Grazie dell'attenzione, buon lavoro.
