[trashware] Re: corso di trashware

[marco.crotta@tiscali.it]

per evitare confusione possiamo rinominare
questo thread della discussione come
"trashmag" ??

Marco


> Carissimi,
> riprendiamo con distensione la discussione...
> 
> per prima cosa l'applicativo è completamente distaccato dall'uso dei
> dati ovvero come voi facevate notare è un misero generatore di query e
> di maschere e, per inciso, tutte le query e tutte le procedure base
> sono riversate in solo 2 file (nella nuova versione) costanti.php e
> cp_module.php ottimamente tandardizzati da Mattia.
> quindi è facilmente riscrivibile in qualunque altro linguaggio.
> 
> la gestione di piu' magazzini è già in fase di sviluppo e secondo i
> nostri intenti sarà abbastanza semplice ovvero introdurremo un secondo
> capo (id_magazzino) nella tabella Tab_mag ed avrà la seguente
> corrispondenza:
> 0 - > magazzino interno dell'associazione
> NN -> codice univoco legato all'anagrafica
> L'associazione potrà quindi interagire solo sul suo magazzino
> id_magazzino = 0 ma potrà solo vedere i dati presenti negli altri
> magazzini.
> logicamente se un'associazione cerca un pezzo e lo trova nel magazzino
> di un'altra ci saranno i dati per poterci mettere in contatto.
> per associazioni con piu' magazzini (e quindi sedi) saranno trattate
> come associazioni per un fatto logistico... se una associazione ha 2
> magazini ben distanti tra loro è probabile che il magazzino presente
> in maniera condivisa non sia aggiornato dei pezzi il lavorazione...
> qualora invece le due sedi fossero abbastanza vicine da permettere un
> reale aggiornamentoo di un unico server ed una reale gestione dei
> magazzini come se fossero un'unico corpo, allora si potrebbe pensare
> di usare un'unica anagrafica impostando il codice univoco in maniera
> differente a seconda che il pezzo sia immesso da una o da un'altra
> sede.
> 
> per le anagrafiche da un piccolo brainstorming è nata l'idea di
> gestire tutte indistintamente con una anagrafica con relativo ID
> univoco.
> l'id puo' venire associato quindi sia all'ingrasso, che all'uscita.
> i campi dell'anagrafica sono in questo momento rivedibili in quanto le
> anagrafiche stesse non sono ancora legate alla tabella pc ed alla
> tabella tab_mag.
> secondo le nostre malsane idee deve essere ancora "inventata" in
> quanto è un po' difficoltoso legare entità diverse (pc o pezzi...) ad
> una entità unica (anagrafica) senza evitare ridondanza di collegamenti
> anche perchè l'entità unica puoi essere un donatore o un ricevente e
> di entrambe dovremmo avere traccia.
> l'idea che avevamo formulato era l'utilizza di una tabella storica
> Tipo (PC - Pezzo)
> storico (entrata, Uscita)
> anagrafica (id_anagrafica)
> Data
> si pone pero' il problema di propagare tali dati quando si parte da un
> pc che non viene sventrato e riassemblato, a ciascun singolo pezzo in
> quanto la provenienza PC -> pezzo non è stata presa in considerazione
> (daltronde se smonti un pc è per cannibalizzarlo )
> 
> infine, l'idea di gestire e di scaricare i dati in formato testo è
> stata attentamente valutata e sono stati presi in considerazione i
> seguenti punti:
> - se io scarico un pc è inutile che mantenga in memoria record di
> pezzi in quanto tali record appesantirebbero le ricerche nella
> tab_magazzino
> - io posso avere bisogno di recuperare i dati in maniera abbastanza rapida
> - chi usa il database di testo è solo la persona che materialmente stà
> mettendo le mani sullo specifico PC in quanto esiste un solo file di
> testo per ciascuno dei PC in lavorazione e/o chiuso.
> 
> rimango in attesa di vostre considerazioni in merito :)
> 
> saluti
> FLavio
> 
> 
> On 10/24/05, Davide Lamanna <davide.lamanna@isf-roma.org> wrote:
> >
> > Caro Flavio,
> >
> > mi dispiace tantissimo che ti sia amareggiato. Mi scuso se il tono della mia
> >
> > email ha dato adito a fraintendimenti, tutt'altro che voluti. A volte lo
> > strumento ML genera di questi problemi di comprensione. Desidero a nome di
> > tutto il gruppo romano rinnovarti stima e affetto.
> >
> > Noi pensavamo che la base di dati dovesse essere piu' strutturata e la parte
> >
> > di PHP leggerissima. Questo era il grosso della questione. In sostanza, i
> > controlli (ad esempio, concorrenza e allineamento) che, nel tuo progetto,
> > dovrebbero essere eseguiti a livello applicazione, dovrebbero invece essere
> >
> > gestiti, secondo noi, a livello DB. La parte di PHP dovrebbe essere, in
> > sostanza, un generatore di query SQL e poco piu'. Altrimenti il DB che ci
> > sta
> > a fare? La sua utilita' non si discosterebbe molto da un file di testo.
> > A proposito di file di testo, noi siamo anche contrari all'uso di file di
> > testo ausiliari nel sistema, in quanto questo contraddice la logica di una
> > buona progettazione e rende il sistema poco performante.
> > Infine, i campi da noi previsti possono ovviamente essere anche ad
> > inserimento
> > facoltativo, dunque non ci sarebbe la necessita' di riempirli tutti.
> >
> > E' possibile che noi si sia solo dei fissati, ma riteniamo che le cose
> > debbano
> > essere fatte in un certo modo, altrimenti gli errori si pagheranno in
> > seguito
> > e cioe' quando il sistema iniziera' a popolarsi di tonnellate di dati e non
> >
> > sara' piu' scalabile.
> >
> > Detto questo e ribadendo che si tratta solo di un punto di vista, includo il
> >
> > file di specifiche da noi messo a punto, attendendo commenti anche dal resto
> >
> > del gruppo. Il tutto in un clima di massima collaborazione e costruttivita',
> >
> > almeno nelle intenzioni.
> >
> >
> > Saluti distesi,
> > Davide
> >
> >
> > Alle 10:08, lunedì 24 ottobre 2005, Flavio Agnoletto ha scritto:
> > > Carissimi dell' ISF Roma,
> > > leggo l'appunto che in un certo senso mi dirigete...
> > >
> > > <flame>
> > > vi faccio qualche piccolo e personale appunto...
> > > 1 - La vostra stutturazione di base dati NON è stata cassato da me ma
> > > da una necessità di rendere snello il programma... se per mettere
> > > dentro un pezzo devo  scrivere 25 informazioni quando ne possono
> > > bastare 5 ho una ridondanza di informazioni... magari voi di
> > > ingegneria avete piu' passione a scrivere chili di codici ma perdere
> > > ore a buttare dentro dati non mi pare molto performante...
> > > 2 - avete dato un mezzo occhio alla base dati ma non mi pare molto
> > > approfondito alla gestioe del programma e quindi dell'ingegneria,
> > > tanto che alcune cose erano già implementate anche se non visibili
> > > nella base dati, pochè gestite come file di testo esterni
> > > 3 - in un'ottica di collaborazione anzichè imporre una base dati (che
> > > tralatro era completamente customizzabile e quindi potevate impostare
> > > i VOSTRI campi fermi restando SOLO i codici univoci di categoria ) vi
> > > si era chiesto di dare una mano a scrivere un po' di codice utile a
> > > qualunque base dati....
> > > </flame>
> > >
> > > disaster-amareggiato.
> >
> >
> 
-- 
marco.crotta@tiscali.it <marco.crotta@tiscali.it>