[trashware] Re: corso di trashware

Lun 24 Ott 2005 17:26:48 CEST

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.
>
>