Micron Engineering ha scritto:
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.
Ah, ma a te sfugge sempre qualche piccolo particolare.....
La possibilità di editare i dati di una Maschera basata su una Query non
è disponibile sempre.
Dipende in effetti dal Front End utilizzato, ed inoltre non è quasi mai
possibile (a meno di giri di valzer...) su query uno a molti.
Senza contare che l'aggiunta di un Record presuppone, nella tua ipotesi,
comunque un lavoro su più Tabelle, passando magari per qualche sana
istruzione Sql.
Tutto per risparmiare campi? No, perchè strutturare i Db come si è
proposto in questa discussione non è certo un modello di semplicità....
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.
Vabbè, se ti astenessi di fare ipotesi sul metodo di lavoro degli altri
senza conoscere i particolari, magari sarebbe meglio.
Qui stiamo facendo una discussione puramente teorica, comunque OT, su
un'ipotesi di partenza abbastanza banale.
Nei casi reali ho vistro strutture di Db di Gestionali anche famosi,
tenute insieme col super attack.
Ognuno ha il suo metodo, e io li rispetto tutti.
Ciao.
--
Filippo Cerulo
blog : http://6of9.softcombn.com/
e-mail : [EMAIL PROTECTED]
web : www.softcombn.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
