Newsgroup: it.comp.appl.access
Titolo: 3.a forma normale disattesa di proposito

Salve, volevo intrattenermi su un problema terico e desideravo leggere 
alcuni vostri pareri.
Ho una tabella con dei campi data nei quali vengono memorizzati l'ultima 
visita medica, l'ultimo emocromo, l'ultimo esame prostatico, l'ultima 
ecocrafia al seno e altri ancora.
Secondo alcuni criteri dettati da un protocollo a cui faccio riferimento le 
date della prossima visita, del prossimo emocromo ecc.. vengono calcolati 
tenendo conto di alcuni dati quali l'età, il sesso, gli anni di lavoro ecc.
In un primo tempo ho costruito la maschera sistemando i controlli 
dell'ultima (visita ecc.)  affiancati dal rispettivo controllo prossima 
(visita ecc). I primi (per semplicità di discorso li chiamo A) sono legati 
ai campi della tabella, i secondi (li chiamo B) non sono legati e il loro 
contenuto viene calcolato tramite una rotine Su Uscita per ciascun controllo 
di tipo A. Le date riportate nei controlli di tipo B sono corrette e questo 
mi sta bene. Il problema sorge tutte le volte che devo andare a utilizzare 
quella data calcolata (nei report, nelle query e perfino in una sessione di 
stampaunione... ) in quando la devo calcolare di volta in volta e sempre 
tenendo conto dei valori dell'età, del sesso ecc. Ora in una routine evento 
è facile inserire i vari if  then e select case, ma in una query o in un 
controllo del report non è così semplice.
Ho deciso di violare la terza forma normale che dice che "i dati dei campi 
devono essere indipendenti fra loro, cioè un dato di un campo non deve 
dipendere dal dato di un altro campo"  e nella tabella ho inserito una serie 
di campi  relativi alla data prossima (quindi dipendenti dal rispettivo 
campo data ultima) che ospitano la data calcolata, così nei report e nelle 
query potrò fare riferimento a questi campi.
Violando tale regola quali conseguenze potrei avere sull'utilizzo e sulle 
porformance dell'applicazione?
Grazie per gli interventi che andrete a fare.
NSantini

 NSantini
Ciao,
Max




Ciao,
Max
Grazie 1000 Max, l'idea della function non l'avevo considerata! Mi sembra 
buona e la proverò, solo credo avrò problemi ad usarla in una sessione di 
stampa unione... perché la lettera tipo che andrei a usare sarà 
all'incirca... la sua visita scade  il <campo data> bla bla. In questo caso 
la function non mi sarà utile ... almeno credo. Accetto suggerimenti. Grazie
NSAntini 


Vincenzo Turturro
Certificato Eucip Core Level
ITA 0000-002299 del 14/05/2007
---------------------------------------------
il sito comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------
risorse Access:
http://www.accessgroup.it
---------------------------------------------
Il sito comune di it.comp.as400
http://www.faq400.com
---------------------------------------------

 ha scritto nel messaggio 
news:br6i83h1vpthpgach...@4ax.com...

Grazie, Vincenzo. non mi aspettavo tanta teoria che comunque apprezzo, ma 
alla fine mi hai suggerito la stessa cosa che mi ha suggerito Massimo 
Piubelli: creati le rispettive funzioni così da poterle richiamare a ogni 
occorrenza. Grazie, ci proverò!
Ciao
NSantini 

 Accetto suggerimenti. Grazie NSAntini
Prova prova...
Ciao,
Max

 apprezzo,
E non c'eri alla cisa...
ti consiglio di leggere il documento di Vincenzo... 
www.accessgroup.it
Ciao,
Max

(.....)

L'origine dati di una stampa unione non dev'essere necessariamente una tabella: può essere anche una query.
Quindi se una delle colonne della query è calcolata tramite una function, la stampa unione che si appoggia alla query
può usarla come se fosse un campo letto da una tabella.


"Massimo Piubelli" <massim...@accessgroup.it.invalid> ha scritto nel 
messaggio news:f6bqe2$cig$1...@tdi.cu.mi.it...
NSantini wrote:


Ciao,
Max
Beh, ma allora sono piccolino nei vostri confronti, non sono uno 
sviluppatore e uso Access per piccole cose personali e da autodidatta.
Sono onorato di ricevere vostri suggerimenti. Grazie.
Ah, ancora un'ultima cosa: seguendo i ragionamenti da cui sono partito, 
anche il campo o meglio "colonna" del codice fiscale è dipendente da altre 
colonne della stessa riga (cognome nome nato sex) quindi non avrebbe senso 
assegnare una colonna solo a esso, quindi anche in questo caso si potrebbe 
ricorrere a una function.
Un caloroso saluto a tutti voi. Ciao
NSantini 

 
no
molti pensano che il codice fiscale si calcoli in base a nome, cognome, 
sesso, luogo e data di nascita
se così fosse ci potrebbero essere dei doppioni: in una grande città capita 
che nascano due mario rossi lo stesso giorno dell'anno (omocodia)
pertanto il codice fiscale è inizialmente 'calcolato' ma viene poi 
'aggiustato' per evitare doppioni
purtroppo diversi software non ne tengono conto e rifiutano un codice 
fiscale 'diverso' da quello calcolato
pertanto il codice fiscale deve essere un campo NON calcolato
trovi più informazioni di wikipedia :)
http://it.wikipedia.org/wiki/Codice_fiscale
-- 
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\