[trashware] DB TrashMag

[Davide Lamanna]

Caro Flavio,

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.

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


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.


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.


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.


Commento finale:

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


Saluti progettuali,
Davide