[trashware] Re: DB TrashMag

Mer 26 Ott 2005 10:06:59 CEST

vediamo un po...

On 10/25/05, Davide Lamanna <davide.lamanna@isf-roma.org> wrote:
>
> Caro Flavio,
Ciao!!!

>
> sarebbe davvero utile avere uno schema progettuale del DB (ad esempio, uno
> schema ER), in quanto molte delle incomprensioni che si hanno via email sono
> dovute al mescolarsi di aspetti progettuali ad aspetti implementativi.

emm ammetto la mia pia ignoranza in materia...
pur avendo alle spalle quanche corso FSE e molti anni di lavoro state
usando terminologia che non conosco... mi date una dritta su come
volete sti schema ?!?!

>
> Proviamo a dire comunque qualcosa.
>
> 1) Ci sembra eccessivo fare la localizzazione per avere un DB distribuito se
> poi abbiamo solo esigenza di accedere in lettura ai DB non locali. E' come
> sparare ad una mosca con un cannone.
> :-)
> Proponiamo invece che ognuno lavori sul proprio DB localmente e si mettano a

Mi esprimo da cani, lo so... abbiate pietà...
l'idea di fondo, venuta tra scotri di testate in faber ed in lista
trash è quella di avere la possibilità nel programma di avere in
memoria anche i dati di altre associazioni...
in particolare ogni associazione ha il suo programma ed esporta
(ipotizzavo in formato testo) la lista dei pezzi che rende disponibili
per fare questo ci sono 2 condizioni
1- identificare in quale associazione è il pezzo (id_associazione dove
"0" è la mia stessa associazione)
2- avere una codifica univoca per il TIPO di pezzo

> disposizio i vari DB o tramite una pagina web sul sito della singola
> associazion o tramite l'accesso ad un solo server per tutti.

>
> 2) Invece di utilizzare una tabella con un numero di campi variabile
> (peraltro all'interno della stessa stringa, vedasi campo "desc" della tabella
> tab_tipo), si potrebbe utilizzare una generalizzazione in base alla
> tipologia  del pezzo.
> Esempio: invece di fare solo la tabella pezzo, si potrebbero aggiungere
> tabelle come scheda di rete, scheda video e scheda audio con attributi fissi

Questa è stata una scelta un po' sofferta all'inizio ma che ha
condizionato la stesura iniziale sia delle tabelle dati sia
dell'applicativo

> e ben definiti. Altrimenti il rischio e' che per cercare un particolare
> attributo di un pezzo si deve ricorrere al parsing della stringa. Che non e'
> bello...

emmmm vedi risposta numero 1...
che è il parsing ???
per capirci l'idea era appunto quello di poter fare una ricerca a
largo spettro su tutto il database pezzi senza discriminazioni...
ovvero tutti i pezzi "tipo=2 (esempio monitor)" dove "desc" contiene "lcd"

> :-)
> La tabella tab_tipo contiene addirittura il numero di attributi associabile
> al pezzo. In sostanza si tenta di implementare a mano una generalizzazione.

Si, questo è lo scopo finale
avere un unico campo standard che contiene in se un numero variabile
di campi e dove poter fare una ricerca senza incorrere in limitazioni
di sorta

nella nuova versione Mattia è riuscito a trasformare la tabella
tab_tipo in un array del tipo associativo, appena a casa metto online
il le modifiche.

> 3)
>
> > - se io scarico un pc è inutile che mantenga in memoria record di
> > pezzi in quanto tali record appesantirebbero le ricerche nella
> > tab_magazzino
>
> Per cercare un pezzo nel DB si esegue un join tra la tabella magazzino e la
> relazione intercorrente tra i pezzi e il magazzino. Se non c'e' il
> collegamento, in fase di ricerca non vado ad impattare in alcun modo sulle
> prestazioni.
> Questo a meno che non si intenda (ma allo stato attuale non c'e' traccia di
> questo nel DB) associare alla tabella pezzo direttamente l'ID del magazzino,
> caso in cui la ricerca implicherebbe (stavolta si') lo scorrimento di tutti
> i   record. Quindi noi sconsigliamo di procedere in questo senso.
> Il vantaggio nel tenere in memoria i record, d'altro canto, e' la completa
> tracciabilita' del PC e di tutti i pezzi che esso contiene. E questo a costo
> zero.

emmmm credo di aver capito il senso teorico ma non pratico.
quando un pezzo è uscito (perchè scaricato in un pc o destinato alla
discarica) abbiamo 2 possibilità
- 1 è un pezzo come un banco di memoria di cua abbiamo N pezzi per cui
a magazzino rimarranno N-1
- 2 c'e' solo 1 pezzo come ad esempio un HD o una scheda madre marcata
singolarmente...
in questo secondo caso la linea del tab_mag avrebbe indicatore di quantità = 0
il ragionamento che mi ha portato e eliminare questo record dal
database è la mera utilità di avere un record che verrà letto e/o
movimentato con estrema difficoltà..
solo se rientro il pc ... o per fare una stampa dello storico dei PC montati...
tanto vale compattare il database ed eliminare i pezzi con quantià =0
salvando pero' una traccia

>
> 4)
>
> > - io posso avere bisogno di recuperare i dati in maniera abbastanza
> rapida
> Accedere un file di testo implica una ricerca esaustiva e dunque tutt'altro
>
> che rapida. A meno che tu non voglia fare il dump del file di testo nel
> magazzino. Ma questo significherebbe ritrovarsi ogni volta con una
> inconsistenza tra i pezzi nel magazzino fisico e quelli nel DB. Ma dubito
> che
> voi intendiate fare un dump inverso.

credo in parte di avere dato le motivazioni della scelta del file "catacombale"
accedere al dato non intendo in fase di modifica ma bensi' in fase di stampa..
se si recupera un PC precedentemente lavorato e marcato basta fare un
Fopen() ,fgets() del file per poter ricaricare i singoli pezzi in
magazzinio... (si vabbe qui' siamo davvero solo allo stato di idea...
nel senso che non abbiamo scritto ancora una riga di codice su questo)

> 5)
>
> > - 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.
>
> Quindi, ci pare di capire, nel file di testo corrispondente al singolo PC vi
> sono i pezzi in esso contenuti. Ma la tracciabilita' dovrebbe essere compito
> della base di dati, non del file di testo. E' un lavoro inutile, in quanto i
> dati sono gia' contenuti all'interno del DB. Con il DB e' sufficiente
> associare il pezzo al PC in lavorazione e non al magazzino.

qui'  mi rode darti ragione...
la racciabilità in entrata non è ancora stata progettata anche se
prevista, come anche la tracciabilità in uscita è stata solo
parzialmente studiata ed implementata.
Per ogni Pc in lavorazione esiste un solo file di testo che è univoco.
in questo file c'e' traccia dei pezzi prelevati dal magazzino
ma non ho modo di tracciare la provenienza del singolo pezzo.
in uscita non esiste ancora una gestione dello storico (o meglio ci
sono delle date significative sulla riga di database tab_PC ) la mia
malsana idea era quella di creare un'altra tabella "progetto" che
legasse i codici univoci dei PC con una angrafica e con una
descrizione di progetto.0

> Commento finale:
>
> Vogliamo lavorare ancora un po' sulla progettazione prima di buttarci a
> capofitto nella implementazione?

Volentieri, credo che bisogna rivedere alcuni processi di base ma non
possiamo stravolgere la base dati se no il lavoro fatto diventa
inutilizzabile...
ti invito e vi invito a iscriverti/vi su savannah cosi' da poterci lavorare su.
su savannah e sul mio micro-cvs (www.alternativenights.net/programmi)
ci sono tutti i file, la base dati e anche un micro manuale, che
voleva essere una traccia per l'impementazione.

posso chiedervi di essere un po' piu' pratici e meno teorici nelle
vostre spiegazioni ?!?!?
non è cattiveria ma se mi dite "fare un join" o "creare delle
relazioni" capisco bene il significato ma un po' meno l'utilità e/o
l'implementazione
come avrete capito sono piu' un coder che un db-engeneer per cui mi
serve qualcosa di reale e tangibile per capire i vostri
ragionamenti...

>
>
> Saluti progettuali,
> Davide

PHP-Saluti
Disaster alias Flavio

>
> --
> Mailing list info: http://lists.linux.it/listinfo/trashware
>