[MySQL] Memorizzare totali o eseguirli ogni volta in query?

[Korenaar]

Salve,
sono di fronte ad un dilemma del quale non riesco a trovare concettualmente il bandolo.

Possiedo una serie di records anagrafici con annessa gestione contabile.

Per farla brevissima, ho bisogno di poter fare ricerche sui totali contabili in maniera certa. E fin qui tutto ok.

Sinora con un sistema obsoleto e precedente,c'era un campo totale continuamente aggiornato e memorizzato, cosa che rendeva molto semplice fare ricerche.

In Mysql/PHP so che questa pratica è assolutamente mal considerata vista la ridondanza del dato. Ma trovo decisamente più problematico rieseguire i totali dell'intero DB semplicemente per fare una ricerca specifica.

Qual'è la soluzione giusta in un caso tipo questo?
Grazie mille!

[nman]

.. un campo totale continuamente aggiornato e memorizzato, cosa che rendeva molto semplice fare ricerche. ...

Forse era semplice fare le ricerche ma certamente non ere semplice tenere aggiornato quel campo .....

tu dirai che lo faceva il DB in automatico, ma comunque devi "programmare" il DB per farlo


Se sei una banca e gestisci da 100 anni il conto corrente della Samsung allora è conveniente mantenere un totale aggiornato piuttosto che ricalcolare tutti i movimenti dell'ultimo secolo

diveramente è decisamente meglio calcolarsi i totali all'ocorrenza senza menorizzarli in tabella


.

[Korenaar]

No non sono una banca
Diciamo che quei record vengono aggiornati non spesso, ma vengono aggiornati. Ci sono i totali di circa 11mila records anagrafici calcolati sulla base di circa 150mila records finanziari associati.

Al momento avevo pensato a stampare questo totale ed ad impostare da un lato una funzione di aggiornamento sul singolo record nel momento in cui viene effettuata un'aggiunta, dall'altro una funzione notturna che andasse per sicurezza a ricalcolare tutti i totali. Dunque soluzione scelta -> salvataggio in un campo. Ma è quella meno ortodossa.

Altrimenti, appunto...si scrive la formula e si fa in modo che la query esegua i totali ogni volta, considerato che per motivi di sistema passo comunque tutti i risultati su una temp tab di riferimento per altre operazioni successive, questo non va ad incidere particolarmente sulla struttura per com'è pensata. Il rischio dall'altro lato è che il sistema debba eseguire diverse decine di migliaia di operazioni ogni volta per passarmi un risultato, il che da un punto di vista della velocità delle ricerche non è forse il massimo.
.
Sbaglio?

[clasku]

non so se possa aiutare in termini di performance, ma usare una View e lavorare su quella?

[zacca94]

Scusate potete essere più specifici che non ho capito?

Si sta parlando di salvare il count totale delle righe in una colonna (tenendola sempre aggiornata) per evitare di dover fare il count su ogni ricerca perchè se poi impostiamo dei criteri di ricerca esso differisce perchè entrano in causa degli WHERE che "falsano" il contaggio, giusto?

Se si sta parlando di questo, io ho sviluppato un metodo poco ortodosso e non molto carino, ma che sicuramente giova all'applicazione.

[Korenaar]

Te lo faccio per punti, e scusami se non sono chiaro ma è tardino:

1) 11mila anagrafica con collegati circa 150k records di dati economici

2) Le ricerche vengono fatte sui totali finanziari, i campi economici sono sono tipo 4 al passivo e 1 all'attivo. Ciascuno di questi campi ha un suo totale (visto che sono records referenziati in modo "n a 1") che non salvo da nessuna parte perchè non interessa a nessuno, mi interessa il saldo finale sul quale vengono fatte spesso e pesantemente delle query su step di saldo non pronosticabili (da 0 a 300 circa qualunque singolo saldo è teoricamente ricercabile)

3) dato che è il saldo a fare dato sensibile, e dato che in un precedente sistema non su database le ricerche venivano fatte sul saldo (che è quindi risultato dei vari campi positivi meno i campi negativi), io avevo in mente di replicare questo sistema, che su MySQL è però poco ortodosso in termini sia di stile di programmazione, sia come regola visto che si tende a non salvare dati ridondanti nel DB (come sarebbe un saldo visto che è ricavabile con una banale somma di altri campi).

4) Sommare i vari saldi ogni volta (e praticamente mai una ricerca ha come unico criterio il saldo) significa costruire un sistema che va a calcolare ogni volta il saldo sull'intero DB, ovvero su 150mila records economici. Il che unito ai vari criteri ulteriori aggiunti ad ogni ricerca diversa, significa fare una query che può metterci diversi secondi prima di risolversi, inaccettabile per un sistema cui saranno collegati insieme al massimo 10 terminali (nella peggiore delle ipotesi, quasi sempre non ci saranno mai più di uno o due utenti contemporanemente).

Spero che ora sia chiaro il concetto.

La mia domanda basilarmente è: me ne frego dell'ortodossia di un sistema che ha queste dimensioni e piazzo una voce "Saldo" con calcolo del totale ad ogni modifica/aggiunta di record economico e con in più di Cron Tab (o equivalente) per riallineare i totali ogni tot di tempo? Oppure quale può essere una buona alternativa che attualmente per limiti sicuramente miei non riesco a focalizzare?

Grazie

[zacca94]

Si tutto molto chiaro, beh che "non sia ortodosso" non so quanto sia vero, perchè io ho studiato abbastanza l'ottimizzazione dei sistemi per sviluppare grossi software e durante la fase di sviluppo ci si pongono due domande:

- Sistema veloce: serve un'applicazione che sia veloce ma che occupi tante risorse? (facebook);
- Sistema scalabile: serve un'applicazione che sia meno veloce ma che occupi meno risorse? (un forum con utenza media);

In base a cosa dobbiamo sviluppare e l'hardware a disposizione optiamo per la soluzione, di conseguenza se per te è il primo caso, io non solo direi che non è non ortodosso, ma indispensabile.

[Korenaar]

Grazie Zacca,
era esattamente la linea di ragionamento che cercavo, in un senso o nell'altro.

Effettivamente ragionando è un piccolo campo in più, nel costo-opportunità è meglio avere uno o due mb di dati in più rispetto ad un lavoro/macchina che pregiudica l'efficienza del sistema. Mi hai dato inoltre una chiave determinante per risolvere questi problemi anche in futuro. Grazie mille e buona domenica!

[optime]

prevedi anche un programma di utilità che alla bisogna riallinei i saldi