Newsgroup: it.comp.appl.access
Titolo: "filosofia" di un database

Vorrei sapere come organizzate voi i database per un problema come quello che segue:
immissione fatture
ogni fattura genera una o piu' scadenze (30/60/90 ecc).
Prima nota: immissione dei pagamenti avvenuti e conseguente aggiornamento delle scadenze dei pagamenti
Ora, io lo sto implementando sfruttando molto gli eventi, cioe' quando inserisco una fattura genero le scadenze e le
registro in un'apposita tabella, quando inserisco qualcosa in prima nota aggiorno la tabella delle scadenze di
conseguenza.
Ma questo modo di fare mi da l'impressione di essere poco "robusto" perche' pone in tabelle persistenti dei dati
derivati da altre tabelle (le scadenze e i pagamenti, ad esempio)
Il modo piu' corretto (almeno teoricamente parlando) sarebbe invece quello di registare solo lo stretto indispensabile
(fatture e prima nota) e calcolare ogni volta tutti gli altri dati: questo pero' renderebbe pesante le elaborazioni.
In genere, come viene gestita questa possibilita' di scelta ? Meglio creare tabelle ridondanti o no ?
Alberto

 wrote in message
38904d38...@news.libero.it...

Inizio dall'ultima domanda: No.
La ridondanza va' evitata il piů possibile.
Ma nel tuo caso (anche se non ho capito molto di cio' che intendi dire) si
tratta di una ridondanza relativa visto che puoi eliminare il record che ti
tiene conto della data di scadenza nel momento in cui non serve piů
(perche', ad es, il cliente ha pagato).
Ciao, Sib
--
------------------------------------------------------
4000 anni fa', il saggio egizio Ptahhotep scrisse:
"... perche' non esistono saggi per nascita."
------------------------------------------------------
Saturiamo ECHELON:
bomba saddam attentato medio oriente

In genere, come viene gestita questa possibilita' di scelta ? Meglio creare tabelle ridondanti o no ?
Ridonda, fidati.
--
Lorenzo Coronati
--
<<Nessuno sa che questa affermazione e' vera>>
(John D. Barrow)
--

(perche', ad es, il cliente ha pagato).
Era proprio questo il discorso. A me sembra piu' pulito, elegante, ecc capire che un cliente ha pagato perche' c'e' una
fattura intestata  a lui, e in prima nota c'e' un pagamento che ci si riferisce. Invece, cancellare la scadenza dallo
scadenzario, sebbene piu' semplice, veloce, intuitivo, renda pero' "sporca" la gestione...
Alberto


Il mondo e' bello perche' e' vario :-)
Due risposte, una il contrario dell'altro. 
Come ho scritto prima, l'ideale' e' un compromesso.
Alberto

La ridondanza va' evitata il più possibile.
Altro esempio, un po' al limite: gestione flussi del magazzino. Carico con bolle dei fornitori e scarico con fatture al
cliente.
L'ideale sarebbe ricalcolare il magazzino in base a tutto il passato, ma questo e' leeeennnnttttooooo e non permette di
gestire cose strane (es: flussi in nero :-) )
Anche qui bisogna ridondare un po'.
Alberto

Due risposte, una il contrario dell'altro. 
Intendevo in questo caso specifico, ovviusli.
Ma di casi dove *bisogna* ridondare ce n'e' a pacchi in un gestionale,
te ne sei accorto anche tu ;-)


 Anche qui bisogna ridondare un po'.
Certo. Io inserisco una campo "Saldo" in ogni record di movimentazione, in
questo modo ho sempre, alla data di qualunque movimentazione, quello che era
il saldo inclusa, ovviamente, la data corrente.
Al piu' si puo' inserire, come ho fatto io, una routine che ricalcola tutti
i saldi se viene fatta una modifica a una bolla perche' era sbagliata.
Voglio aggiungere che non ho dato una risposta opposta a quella di Lorenzo,
infatti ho detto che "in linea di principio" non si deve ridondare (ad es
nei dati della fattura non riporterai ragione sociale e indirizzo del
cliente, ma solo il suo ID evitando, quindi, inutili ridondanze), ma nel tuo
caso (che esula dalla "linea di principio" che citavo, ti ho suggerito di
ridondare.
Ciao, Sib