Filippo Cerulo ha scritto: > Micron Engineering ha scritto: >> ora... a me sembra sia meglio: >> >> TAnagrafica: >> IDAnag, AziendaPersona, IDAziendaPers >> >> TAnagAziende: >> IDAzienda, RagSociale, PIVA >> >> TAnagPersoneFisiche: >> IDPers, Cognome, Nome, CodiceFiscale >> >> TIndirizzi: >> IDIndirizzo, Nazione, Città, CAP, Via, NumeroCivico, Telefono, Fax, >> Email, Cellulare,WWW, IDAziendaPers >> >> TConti: >> IDConto, TotOrdinato, TotPagato, TotScaduto, IDAziendaPers >> >> dove i campi ID sono le foreign key tra le varie tabelle. L'unica fk che >> merita descivere è IDAziendaPers che si relaziona con IDAzienda o IDPers >> in funzione di quali record filtrare. >> > Potrebbe anche essere meglio, se non fosse che, oltre a progettare la > maschera di immissione, ci devi fare un bel lavoro dietro per mettere > tutti i dati al posto giusto..... per questo esistono le query. Le tabelle non devono essere pensate in funzione dei dati da presentare in un report o in una maschera, devono essere un sistema efficiente di memorizazione, diciamo il livello più basso, il livello intermedio sono le query che forniscono i dati che servono per maschere e report. In sostanza una maschera o un report dovrebbero ricevere i dati da una query e non direttamente da una tabella. E comunque non è un lavoro gravoso e permette l'espandibilità del db al cambiare delle esigenze, il tutto in modo molto flessibile. Purtroppo tu come molti altri vi concentrate troppo sulla presentazione dei dati e non sull'implementazione/gestione. Un pattern molto utile da seguire è MVC che razionalizza la struttura dell'applicazione.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
