Newsgroup: it.comp.appl.access
Titolo: Come tenete i valori di esistenza / ordinato / impegnato .....

Sarei curioso di sapere, per chi di voi ha gia' realizzato un qualcosa che 
somigli ad una gestione magazzino, come tenete i valori di esistenza / 
valore / impegnato ecc per ogni articolo
Li andate a visualizzare dinamicamente in base ai movimenti di magazzino 
disponibili oppure tenete memorizzati questi valori nell'anagrafica 
dell'articolo e li modificate quando viene movimentato l'articolo stesso ?
Ci sono pro e contro in entrambi i sistemi
Sarei propenso a tenere le visualizzazioni sempre in funzione dei movimenti 
disponibili, calcolando al volo tutto, ma l'impegno computazionale diventa a 
volte notevole
D'altra parte, tenere i valori 'attaccati' all'anagrafica articolo (o giu' 
di li), potrebbe portare ad un disallineamento dei valori reali nel caso che 
qualche modifica/eliminazione non aggiornasse correttamente i valori 
nell'articolo stesso
Attualmente, per velocizzare la visualizzazione dell'esistenza articolo, 
utilizzo il secondo metodo
Pero' mi piacerebbe molto usare il primo
Come fate voi ?
Ciao e grazie
RobertoA


Il primo.
Il motivo è proprio quello che dicevi tu come inconveniente della seconda soluzione (beh lo dice anche la 3 forma normale).
Per quanto riguarda il calcolo nulla che una buona query ben strutturata non regga
select P.id, P.Codice, P.DescrProd, Acq.Acquisti
FROM T_Prodotti as P 
(LEFT JOIN 
(SELECT Rif_id, SUM(Qtà) As Acquisti, Mov FROM T_Movimentazione 
GROUP BY Rif_id, Mov
HAVING Mov = 1) as Acq ON P.id = Acq.Rif_id)
L'ho scritta a volo quindi è probabile ch eci siano imprecisioni
ma in soldoni il discorso è 
se hai una tabella unica delle movimentazioni e le dfferenzi per il campo numerico mov
il gioco è fatto (un truccheggio: evita valori nulli nella movimentazione e usa invece quelli numerici)
-- 
-- 
MAssimiliano Amendola
www.accessgroup.it
Cisa - Conferenza Italiana Sviluppatori Access


il gestionale che usiamo in negozio (buffetti) fino alla release
precedenti memorizzava le quantità (esistenza/impegnato etc) in una
tabella specifica,con la nuova versione invece il tutto viene
calcolato al volo ed il risultato è stato pessimo, tempi di attesa
lunghissimi per qualsiasi operazione tipo visualizzazione ultimo
prezzo,quantità movimentate..etc etc.
considerando che il database è sqlserver o è un problema degli
sviluppatori oppure è proprio l'idea che è sbagliata.
(per avere un'idea dell'ordine di grandezza sto parlando di un db da 1
gb, con circa 30000 articoli ed una movimentazione giornaliera di
circa 500 articoli.)



Con questi volumi e considerando che si parla di SQL è decisamente un problema Software (ovvio se l'hardware è ok).
Con questi volumi anche Jet schizza come una scheggia
-- 
-- 
MAssimiliano Amendola
www.accessgroup.it



La memorizzazione delle giacenze reali ha vantaggi enormi sui tempi di
esecuzione...!
Pensa alla pesantezza di un Magazzino con volumi di movimenti notevoli
in caso di calcoli delle giacenze al volo per anni...
A mio avviso è una scelta poco funzionale che degrada esponenzialmente
nelle prestazioni.
I movimenti servono per tenere traccia contabile e gestionale, ma la
giacenza è meglio  gestirla separatamente.
IMHO.
@Alex


e se si utilizzassero entrambe? una tabella per le statitiche ed una
funzione di "riallineamento" che fa la somma dei movimenti e li
riporta sulla tabella. la funzione di riallineamento potrebbe essere
chiamata solo l'utente riscontra qualche problema..

 chiamata solo l'utente riscontra qualche problema...
Premesso che come ha detto anche Massimiliano in caso di Volumi non
enormi la soluzione è ottima, poi si possono mettere in essere azioni
personalizzate, ritengo però sempre doveroso distinguere il ruolo di
controllore(al quale possono anche far comodo queste procedure anche
se si perdono 10secondi) da quello di Utente, al quale sicuramente
impiccia molto per ogni ITEM dover risentire dei tempi di attesa, ed
al quale non serve nulla sapere se quel determinato ITEM è stato
prelevato per un motivo o per un'altro...!
Poi in un gestionale ci sono sempre molti modi di procedere, che
dipendono moltissimo anche dalla complessità della struttura
aziendale.
@Alex