Newsgroup: it.comp.appl.access
Titolo: qual'è la soluzione migliore?

Ciao
Devo creare un report piuttosto complesso.
Domanda: meglio basarlo su una query di selezione con 17 tabelle collegate 
ad una principale oppure mettere 16 sottoreport?
Ho un dubbio sulla velocità di stampa....
grazie per la risposta......buon fine settimana a tutti 

Ciao
Devo creare un report piuttosto complesso.
Domanda: meglio basarlo su una query di selezione con 17 tabelle collegate
ad una principale oppure mettere 16 sottoreport?
Ho un dubbio sulla velocità di stampa....
Se possibile, è chiaramente meglio una query di selezione con 17 tabelle
collegate...
Ciao, Simone

Credo che la domanda sia un pò strana...!
I risultati ottenibili sono decisamente poco confrontabili a livello di
presentazione Report...!!!
Tutto dipende da cosa devi esporre e come, anche se personalmente non
ho mai avuto a che fare con situazioni così complesse.
Spero non sia colpa di un'errata normalizzazione del Database.
@Alex

 ha scritto nel messaggio 
news:e42cpu$osc$1...@carabinieri.cs.interbusiness.it...
Ciao
[risposta]
Quella di scrivere sempre un oggetto descrittivo del problema...
Ciao.
-- 
Sergio MAZZA 


per favore sistema l'orario del PC
--
ac

Scusate, effettivamente ho esposto il quesito partendo dal risultato 
finale....
Praticamente si tratta di un db che gestisce l'inserimento dati di un 
laboratorio tecnologico che effettua prove su materiali elastomerici (pvc, 
tpo ecc ecc).
Ogni volta che si produce un materiale viene dato un codice che comprende: 
il nome del materiale, lo spessore e la data.
Questi dati finiscono in una tabella denominata "anagrafica"
Poi, a seconda del tipo di prova effettuata (carico a rottura, 
allungamento a rottura, peso specifico, massa areica, spessore, 
lacerazione, flessibilità a freddo, invecchiamenti in stufa ecc 
ecc...circa una ventina), attraverso opportune maschere (ognuna diversa 
dall'altra), viene richiamato il codice relativo al materiale provato e si 
inseriscono tutti i dati della singola prova (quindi una ventina di 
maschere con relative tabelle).
Ad ogni maschera ovviamente è associata una tabella e ad ogni tabella una 
query di selezione che effettua i calcoli sui dati inseriti (valori medi, 
somme, divisioni, formule ecc ecc).
Alla fine deve essere stampato un report dove, nell'intestazione devono 
comparire tutti i dati "anagrafici" del materiale e sotto tutte le prove 
effettuate sul materiale stesso con i singoli valori ottenuti e i valori 
medi.
Pertanto, mi chiedevo, se fosse meglio basare il report su una query 
(tabella "anagrafica" con legate a questa tutte le query relative alle 
singole prove) oppure se basare il report sulla tabella "anagrafica" e poi 
inserire tanti sottoreport  (uno per ogni prova effettuata)
Spero di essere stato chiaro
Ciao a tutti......

Beh sono semplici prove meccaniche su provini....!
Da come hai esposto lo sviluppo ipotizzo l'errata normalizzazione
del DB come avevo sostenuto.
Io gestisco prove su strumentazione di apparecchiature differenti
ma non ho di certo una tabella per ogni tipo di prova...!
Ogni apparecchiatura ha diversi strumenti e su ogni strumento eseguo
diverse prove...!
Ho una tabella generica di tutte le prove che possono essere effettuate
nel mio laboratorio.
Una tabella che associa le prove al Tipo di strumento, non allo
strumento ma al TIPO.
Quindi quando devo inserire una Prova recupero le proprietà da
inserire
per il determinato strumento compresi i valori previsti e quelli di
attenzione per
i confronti, quindi valido i dati da censire(ed eventualmente ne
elimino o ne aggiungo)
quindi salvo i dati una tabella.
Per questo passaggio uso un Recordset in memoria ADO, ma si potrebbe
usare una
TempTable con DAO.
Ho realizzato uno sviluppo Verticale invece che Orizzontale come in
effetti
verrebbe in mente di fare.
Questo mi permette di ottenere la massima flessibilità per tutte le
prove e
per tutte le apparecchiature.
La gestione è apparentemente più complessa ma non ho limiti nè
confini, anche
perchè sfrutto la struttura Gerarchica nelle tabelle, cosicchè ogni
proprietà è/può essere figlia
di una proprietà, in questo modo realizzo le proprietà per
categoria...ecc...!!!
Per farla breve alla fine ho un Report che estrae i dati da una tabella
principale e 3 Tabelle
per l'AutoLookup dei dati indicizzati.
Saluti
@Alex

Forse non ho capito....
Secondo te posso creare una unica tabella per contenere tutti i dati che 
ottengo da prove diverse?
Faccio un esempio:
la prova di allungamento a rottura viene effettuata dieci volte sullo 
stesso materiale prendendo i provini in zone diverse.
Quindi ho creato una tabella "allungamenti" con:
codice
data di analisi
provino1
provino2
provino3
.....
provino10
la prova di peso specifico viene effettuata tre volte sullo stesso 
materiale quindi ho creato la tabella "pesosp" con:
codice
data di analisi
peso1
peso2
peso3
Faccio notare che i valori di peso specifico e di allungamento sono con 
decimali diversi.....
ciao

Ti sfugge il concetto di sviluppo verticale...!
Ti confermo che non servono tante tabelle quante sono le prove, ma
una buona razionalizzazione di poche...!
La struttura da te creata è contro la normalizzazione, è fallace in
partenza
e sarà sempre peggio non essendo flessibile.
Se ti chiedessi cosa fai in caso di una nuova prova...?
Se ad una domanda simile la tua soluzione sarebbe creare una nuova
tabella
capisci da te che il tuo approccio non potrebbe stare in piedi, quando
mai si è
visto un applicativo rigido che richiede l'intervento radicale sulla
struttura in caso
di aggiunte....?
Questo dovrebbe sempre essere un campanello d'allarme.
Come ti dicevo Tabella Prove nella quale avrai:
Provino1
Provino2
Provino3
Provino4
ProvinoN
Peso1
Peso2
Peso3
Attributo1
Attributo2
AttributoN
Proprieta1
Proprieta2
ProprietaN
ecc.....!
Una tabella nella quale inserisci i tipici prove.
Una tabella nella quale relazioni i TIPICI con le prove
Quindi Ogni Tipico ha il suo elenco di prove.
Quando esegui una prova una Query per Tipico del campione
e ricavi in Verticale l'elenco delle Prove.
Inserisci i valori e salvi un una Tabella dedicata.
Come vedi sono 4 tabelle....!
La difficoltà è uscire dallo schema rigido della struttura
orizzontale
che in questo caso non è applicabile.
Ciao
@Alex

ca...@flag.it
 wrote:

In situazioni del genere ti crei una o più tabelle temporanee.
Le popoli con tutti i dati che ti servono nel report operando con query
successive.
Alla fine il report si limita a presentare le tabelle senza filtri o altro.
Ciao

In una situazione del genere è la struttura del DB a non essere
corretta.
@Alex

 Ciao
E' già la seconda risposta che dai oggi, senza prima aver letto il Thread...
Ciao, Simone

Oggi hai il tuo PH potrebbe essere definito come la derivata di una
costante ...... ----> tendente a Zero....!!
;-)
Io invece devo avere il Ph dello stomaco in subbuglio sono quasi
zavorrato....
Ma data la mole di risposte che oggi Paolo ha dato nel NG qualcosa gli
è pure
scappato infondo è domenica...!
Ciao Simone.
@Alex

 scappato infondo è domenica...!
Diciamo che oggi pioveva e mi rompevo le p..
Di conseguenza ho pensato di dare una ripassata al mio vecchio gruppo (è un
po che non ci bazzico).
Certi treads erano spezzati qua e la per cui effettivamente qualcosa mi è
scappato.
Ciao

 scappato.
Ma te l'avrei "lasciata passare" se ti fossi firmato col nome completo: al
fondatore dell'area Access si può concedere qualche distrazione, no?   ;-)
Ciao, Simone

Era in incognito per vedere se qualcuno che si rompeva altrettanto
faceva osservazioni.....
E' toccata a te Simone.
Quà dalle mie parti oggi era una spendida giornata, 24°C con un sole
splendido dopo le 10
quando ha spiovuto.
Ciao a tutti buon inizio settimana
@Alex

ciao
Purtroppo non ho ben capito la tua spiegazione.
Esiste un esempio simile sul sitocomune che mi aiuti nella comprensione di 
questo sviluppo verticale?
grazie.......ciao

Purtroppo no e non saprei come aiutarti più di come ho fatto perchè
è proprio un problema strutturale da sviscerare.
@Alex

 ;-)
Col cognome che mi ritrovo non vi si può mai nascondere nulla
:-)