Newsgroup: it.comp.appl.access
Titolo: tabelle e relazioni

Sto progettando un db per gestire la movimentazione di contenitori. La
TblContenitori (IDCntr, Sigla, Numero,...) è relazionata molti a molti con
la TblOperazioni (IdOp, TipoOp, DataOp). Per ogni TipoOp ci sono diversi
dati da memorizzare. Ad es per il TipoOp “Sbarco” avrò una tbl con i
seguenti campi: Merce, Peso,... , mentre per il TipoOp “Carico” avrò una
tbl con i seguenti campi: Stato, Danno,... . Da qui l’esigenza di
relazionare un record specifico di TblOperazioni con la sua specifica tbl.
Si può fare? C’è qualcosa di sbagliato nel mio ragionamento? 
Grazie in
anticipo per la disponibilità e la pazienza
--------------------------------
Inviato via 
http://usenet.iol.it

 ha scritto nel messaggio
news:217Z57Z214Z92Y...@usenet.iol.it...

Penso che sia ragionevole affermare che la struttura dei dati di un
database, e quindi delle sue tabelle, vada valutata in funzione delle
informazioni che vuoi ottenere.
Ritemgo che sia difficile darti una dritta sulla struttura delle tabelle e
delle loro relazioni se non si sa a cosa servoni i dati in esse contenuti;
"gestire la movimentazione di contenitori" può essere significativo
solamente per chi ha già affrontato l'automazione del problema specifico.
--
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------

---------------------------------------------
Hai ragione, me ne sono
accorto anch’io rileggendo il post. Mi scuso con te e con tutto il NG. 
Ho
cercato di dare una veste “pratica” ad un mio dubbio “teorico” riguardo il
concetto di tabella come “insieme di dati relativi a un argomento
specifico” (help docet). Cercherò di fare un esempio di + facile
comprensione: in un post precedente si cercava di dare una soluzione ad un
problema simile al mio riferito ad un db per un laboratorio farmaceutico:
Il problema era se strutturare il db con 1 TblClientiPersone + 1
TblClientiAziende oppure riunire le 2 in un'unica TblClienti. Soluzione
consigliata: tbl unica! E se le 2 tbl avessero campi diversi? Si
creerebbero inutili campi vuoti. Sei d’accordo? E’ possibile 
p.es
. che la
TblClientiAziende abbia 2 indirizzi x record (SedeLegale, SedeOperativa),
mentre la TblClientiPersone debba memorizzare anche l’età del cliente, il
colore dei capelli, l’altezza (per essere assurdo). Come mi comporto in
questo caso? 
Mi sto facendo troppe seghe mentali? Hai ragione di nuovo,
ma è da un po’ che ci sbatto contro la capoccia e non trovo una soluzione.
Pierpa


 ha scritto nel messaggio
news:217Z57Z214Z92Y1...@usenet.iol.it...

Io ho partecipato al thread cui fai riferimento; in quel caso la
problematica era abbastanza chiara e la domanda lo era altrettanto: si
chiedeva se, in una procedura di fatturazione e postfatturazione era meglio
avere un'unica tabella clienti con dei campi non sempre utilizzati oppure
due tabelle strutturalmente differenti, una relativa alle persone fisiche ed
una relativa alle persone giuridiche; visto che bene o male si conoscono le
problematiche della fatturazione e postfatturazione non è stato difficile
dare la risposta, anche perché era innegabile che la natura dei dati era
omogenea.
Il tuo caso è, a mio avviso un pochino diverso; non so quanti frequentatori
sel NG conoscano le problematiche legate all'informatizzazione della
movimentazione dei containers e quindi non si ha la certezza se i dati
relativi allo "Sbarco" sono omogenei, ai fini procedurali, ai dati dei
"Carichi" (il fatto che siano riferibili alla stessa Sigla e Numero di
contenitore non è sufficiente a decidere); solo tu sai se i dati dei vari
tipi di operazione vengono immessi con un iter temporale e procedurale
uguale oppure no; solo tu sai se i dati dei vari tipi di operazione debbono
sempre essere proccessati insieme per produrre gli output della procedura;
solo tu sai se gli sprechi di campi vuoti sono o meno tollerabili, visto che
solo tu sai i volumi dei record da trattare. E se gli sprechi su disco non
sono determinanti, io la scelta la farei solo in base alla soluzione che mi
costerebbe di meno come sviluppo del progetto e/o in base alla soluzione che
mi garantisce la maggiore flessibilità per gli sviluppi procedurali futuri
senza dover risconvolgere tutto il database.
Insomma, vedi di chiarirti meglio circa le informazioni che vuoi ottenere
dalla procedura e poi vedrai che sarà mooooolto più facile decidere come
devi organizzare i dati, quindi le tabelle: certi percorsi decisionali
diventeranno quasi obbligati.


---------------------------------------------
Mi tocca darti ragione
ancora una volta.
Grazie per la dritta.
