Newsgroup: it.comp.appl.access
Titolo: Gestione storico

Salve a tutti,
quando si lavora con database di grandi dimensioni diventa opportuno
eseguire uno svuotamento annuale e archiviare i dati da qualche altra parte.
io ho sempre gestito la cosa in un certo modo, ma vorrei riflettere un
attimo su quale possa essere il modo migliore per avere un db di lavoro il
piu' snello possibile mantenendo la possibilita' di accedere ai dati degli
anni precedenti per il datawarehouse.
Quindi vorrei aprire un dibattito sull'argomento, cosi' ci scorniamo a
vicenda (;-) e magari ne viene fuori qualcosa di buono.
La seduta e' aperta.
Sib
--
http://sib.ionwd.com
http://www.sitocomune.com

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:ZzyW9.22093$ZE.6...@twister2.libero.it...

intanto potresti dire cosa intendi per grosse dimensioni.
poi se il database contiene dati contabili non mi sembra il caso di
svuotarlo ogni anno.
Io cerco sempre di tenere almeno 5 anni in linea per la contabilità
ciao, AEOM

 Io cerco sempre di tenere almeno 5 anni in linea per la contabilità
Hai sviluppato una contabilità fiscale?

 ha scritto nel messaggio
news:5AzW9.22105$YG2.6...@twister1.libero.it...

se per fiscale intendi redazione dei registri iva, libro giornale, bilanci
si
ciao
AEOM

 si
Complimenti.
Ciao.

 anni precedenti per il datawarehouse.
Quindi si sta parlando di database JET e di volumi di dati enormi (centinaia
di migliaia di records x anno in più tabelle), giusto?
Esistono alcuni accorgimenti per mantenere DB Jet compatti: non usare campi
OLE, evitare d'indicizzare a destra e a manca, non usare indici multicampo,
etc.
Ma se anche così il DB è enorme e l'azienda ha esigenza di far statistiche
pluriennali su grandi volumi di dati, l'unica è scalare l'applicazione a un
BE Server.
Probabilmente la tua richiesta è legata al fatto che non hai voglia/tempo di
"upsizare" le ditte in questione?
Ciao, Simone

 ha scritto nel messaggio
news:UeAW9.22530$ZE.6...@twister2.libero.it...

non è che ci voglia poi molto sai.
ciao
AEOM

 non è che ci voglia poi molto sai.
Beh, insomma: strutturare un sistema di causali contabili da agganciare a
una Prima Nota con tutti gli armenicoli di una contabilità (Fatture,
Corrispettivi, IntraCEE, Iva in sospensione, etc.) non è cosa da poco.
Ciao.

 svuotarlo ogni anno.
Il database di contabilitą l'ho tenuto appositamente separato.
la difficolta' consiste in quete funioni:
consentire di lavorare sull'anno di esercizio desiderato
elaborare statistiche pluriennali
mantenere le elaborazioni dell'anno in corso performanti
probabilmente la soluzione corretta e' un msde.
Sib


MSDE
ciao,
AEOM

 MSDE
Laconico ma definitivo :-)
concordo con te in effetti, ma volevo trascinare la discussione sul problema
sottovalutato (da me in primo luogo) del datawarehouse.
qualcuno tempo fa aveva proposto di affrontare il problema, e io volevo
riaprirlo.
l'elaborazione statistica di grandi quantita' di dati richiede grandi
strutture denormalizzate per evitare pesanti elaborazioni di ripescaggio e
ricalcolo dei dati. ma come conciliare questa esigenza con quella di
apportare modifiche ai dati di origine?
Sib


scusa sarà l'ora e un algoritmo genetico di cui non ne vengo a capo ma non
ho capito bene il tuo discorso finale.
In particolare cosa intendi per strutture denormalizzate (ho preso paura)!!!
Lo puoi riformulare?
ciao
AEOM

 ha scritto nel messaggio
news:QoAW9.22292$YG2.6...@twister1.libero.it...

Scusate se mi introduco, ma questo della gestione degli "storici" interessa
parecchio anche me.
A parte le dimensioni, a volte non trascurabili, degli archivi, si tratta
anche di "pulizia" che periodicamente, foss'anche dopo 5 anni, andrebbe
fatta!
Rimane però il problema di come "separare" l'attuale dallo storico pur
lasciando la possibilità, per statistiche o semplice riconsultazione, di
visionare il pregresso.
E non solo per prg. di contabilità, ma + in generale per qualsiasi DB,
indipendentemente se con Jet o SQL server!
Per il momento io non ho ancora dedicato molto tempo alla risoluzione del
problema, ma mi piacerebbe sentire il vs. parere in merito.
Al


Of course.
Contravvenendo alle raccomandazioni di Socrate, passo direttamente
all'esempio pratico.
Una azienda "produce" 100Mb di dati l'anno, piuttosto complessi e da
elaborare in modo articolato per le statistiche.
Per quanto riguarda le statistiche pluriennali, si avrebbero in condizioni
normali delle elaborazioni molto pesanti da eseguire, invece, dato che i
dati degli anni precedenti sono "statici", l'elaborazione la faccio una
volta e conservo i risultati in modo da unirli all'elaborazione dell'anno in
corso.
Tutto sembrerebbe risolto, ma il problema sta nel cambio d'anno, infatti
puo' verificarsi di dover lavorare contemporaneamente con due anni di
esercizio con modifiche dell'ultimo minuto all'anno precedente, pero'
facendo modifiche all'anno precedente le elaborazioni salvate vanno rifatte
(con non pochi problemi).
Tenere i due anni potrebbe anche andare a livello funzionale, ma
elaborazioni complesse su 200Mb di dati  reali (mdb compattato) non sono
facili da digerire per un cliente che richiama le statistiche ogni dieci
minuti (mentre altri utenti continuano a inserire dati).
Sib

 Sib
ho capito....
non mi sono mai imbattuto in questo genere di problemi.
ma potresti archiviare i dati elaborati di due anni prima (visto che molto
probabilente non saranno mai più modificati) e unirli a quelli elaborati a
run-time degli ultimi due anni.
Mi impressiona il fatto di statistiche pesantissime da  richiamare ogni 10
minuti, di cosa si tratta?
pesantissime =secondi?minuti?ore?
AEOM

 pesantissime =secondi?minuti?ore?
per un anno 15 - 30 secondi ma sono maschere  e report che vengono aperte e
stempati ogni 10 minuti.
Sib