Italian [B4J] Come memorizzate le esistenze degli articoli?

[amorosik]

Supponete di avere il classico gestionale che fa ddt/fatture/ordini ecc
Supponete di avere piu' depositi nei quali il materiale/prodotto viene tenuto dall'acquisto fino alla vendita, deposito1, deposito2, deposito3
Deve essere ovviamente disponibile, rapidamente, l'informazione relativa all'esistenza attuale di ogni articolo sia su ogni deposito che il valore totale (in questo caso la somma dei tre depositi)

Bon, detto questo, la domanda e': come fareste a tenere traccia dell'esistenza attuale di ogni articolo su ogni deposito?

Chiedo questo perche' vedo che si usano diversi metodi, c'e' chi aggiorna l'esistenza direttamente su un campo del record articolo, c'e' chi ricalcola al volo partendo dalle righe dei documenti, c'e' chi memorizza separatamente dei 'movimenti di magazzino' in corrispondenza di ogni riga documento, ecc...
Per ogni sistema ci sono dei pro e dei contro
Che metodo usate voi per tenere aggiornata l'esistenza di ogni articolo?

 

[giannimaione]

di solito oltre le tabelle documenti, memorizzo il dettaglio con tabelle "movimenti" e con l'utilizzo delle VIEW (mysql/dbmaria) ricavo in modo veloce le giacenze;
per le interrogazione dei vari punti vendita (deposito), dipende dove vengono "concentrate" le giacenze (db), ovvero se i dati possono essere interrogati da remoto.

 

[amorosik]

di solito oltre le tabelle documenti, memorizzo il dettaglio con tabelle "movimenti" e con l'utilizzo delle VIEW (mysql/dbmaria) ricavo in modo veloce le giacenze;
per le interrogazione dei vari punti vendita (deposito), dipende dove vengono "concentrate" le giacenze (db), ovvero se i dati possono essere interrogati da remoto.

Lasssiamo stare i dati da remoto, per ora
Quindi per sapere l'esistenza dell'articolo XYZ su deposito1 e deposito2, tu fai 'al volo' la lettura sulla tabella 'movimenti' dei carichi/scarichi eseguiti dal'ultimo inventario in poi, quindi tutto in real-time?
Se cosi' fosse, e dovessi realizzare ad esempio una stampa con articolo-prezzo-esistenza , anche ci mettesse 100 mSec il calcolo esistenze di un articolo, per finire la stampa di 10.000 articoli ci metterebbe 1000 secondi, magari fa' anche prima ma comunque diventa moolto pesante
Quindi dici che memorizzare l'esustenza attuale da qualche parte, con possibilita' di lettura istantanea ma non sempre di valore preciso, non sia consigliabile?
Come ho scritto sopra, chiedo prche' vedo che esistono diverse scule di pensiero e vorrei capire esattamente i pro e contro di ogni sistema

 

[giannimaione]

SELECT
m.idarticoli AS idart,
a.descrizione,
sum(case when m.tipo = 'C' then m.qta ELSE -m.qta END) AS giacenza
FROM movime AS m
LEFT JOIN articoli AS a ON a.id = m.idarticoli
GROUP BY m.idarticoli 

'in questo esempio ci sono due tabelle:
'movime e articoli
'nella tabella movime ho il campo "tipo" che viene valorizzato con "C" oppure "S" (carico/scarico)
'eseguo una query su TUTTO il file movime (puoi aggiungere qualche WHERE, ecc)
'e ottengo qualcosa del genere

'idart | descrizione | giacenza
10|matita stilo|123
18|penna stilo|55

 

[amorosik]

Si ho capito, che tu faccia una funzione per leggerti la giacenza sommando i valori presenti nella tabella 'movimenti' oppure che metti il conteggio nella query e' la stessa minestra, da qualche parte ste somme deve farle
Se hai qualche decina di migliaia di articoli e 'movimenti' da centinaia di migliaia o milioni di righe, non la vedo proprio rapida rapida la cosa
Nel senso che fare un pdf con la stampa di tutti gli articoli, con esistenze calcolate 'on-the-fly', non ci ho mai provato ma non mi da' l'idea di qualcosa da secondi ma dell'ordine dei diversi minuti, non dico sia inaccettabile ma se ci fosse un'alternativa sarebbe preferibile
O hai esperienze diverse?

 

[giannimaione]

O hai esperienze diverse?

sì, certo. ho la tabella "contabile" degli articoli (quantità e valore carico .... quantità e valore scarico ... ed altre info);
ma quante volte ho dovuto RIAGGIORNARE la tabella perché non c'era QUADRATURA tra i dati "contabili" e il dettaglio "movime";

db con milioni di righe !? ... non ho esperienza in tal senso, cioè con una select on-the-fly;

è da provare:
dispongo di un tabella articoli (oltre 20000), con relativi movimenti;
ti tengo informato

 

[giannimaione]

vale la pena aspettare!!!

10.000 articoli
800.000 righe movime
tempo medio per eseguire la select (vedi post #4) : 8 secondi !!!

mariadb, pc 8gb, un "misero" celeron J1900 1.99GHz

 

[amorosik]

Informazione molto utile, grazie
Certo che se i tempi sono dell'ordine dei secondi o anche decine di secondi, si puo' attendere sicuramente
Discorso diverso sarebbe stato se fossero state necessarie decine di minuti, allora sarebbe stato inaccettabile
Non e' che riesci ad accodare una decina di volte quei 10K e fare una tabella da 100K articoli?
Giusto per vedere come cresce il tempo in funzione dell'ampiezza tabella articoli

 

[giannimaione]

intanto volevo fare qualche test con gli indici

In una applicazione con tabelle molto piccole gli indici non fanno molta differenza, ma appena le tabelle diventano più grandi delle dimensioni del buffer gli indici cominciano a incrementare notevolmente la velocità.