[Db] prima nota et similia

[Domenico L.]

Marcello Vezzelli ha scritto:
> Ciao a tutti,
> visto che la ml comincia a lievitare e ci sono thread interessanti di 
> progettazione, vi pongo il mio quesito:
>
>  La prima nota è relativa alla cassa principale.
ehm... prima nota, prima nota... uff eppure dovrei sapere cos'è!

>
> Inizialmente avevo previsto una struttura più generica possibile, ma 
> la situazione diventava complessa rapidamente e correvo il rischio di 
> introdurre errori nel computo di cassa.
>
> Sto meditando di fare una struttura forse non ottimale, ma che mi 
> permette un controllo maggiore su tutto il conteggio... ovvero 1 
> record con 25 campi per le entrate fisse giornaliere (PK di tipo 
> data), poi una tabella per cassa con i movimenti incrociati relativi a 
> quel giorno (PK surrogata, il solito autoincrementante).
Bruttissimo

I 25 movimenti fissi li puoi numerare facilmente giorno per giorno, ma 
soprattutto non capisco perché fare una tabella per cassa, ti complichi 
tremendamente la vita senza alcun vantaggio. Non p meglio una tabella 
unica con un campo che definisce la cassa?

Per la tabellona con i 25 movimenti, sono sicuro che sia in effetti 
molto comoda per i riepiloghi, quindi, secondo me, è avere una tabella 
movimenti che, con opportuna procedura compila i dati della tabella 
riepilogo

>
> Per evitare di sommare molti record e fare troppi conti, sto pensando 
> di inserire una "chiusura" nel giornaliero, con i saldi delle casse, 
> visto che gli inserimenti retroattivi vanno al massimo 15 giorni 
> indietro.
> In questo modo, faccio i conti dall'ultima chiusura fino al giorno 
> attuale (dovrò farli lato applicazione senza usare SUM).
> In questo modo, ad ogni aggiornamento, devo scorrere un numero di 
> record basso...
Perché mai non puoi usare sum? credo che basti flaggare opportunamente i 
record di tipo chiusura e i record di oggi.

a questo punto ti serve una cosa come: dataInserimento, dataRiferimento

> Poi devo aggiornare tutti i record con le loro chiusure giornaliere 
> quando si fa un inserimento retroattivo per avere una situazione 
> sempre coerente.
In questo caso non ti servono le due date... forse un flag boolenao 
completato

Mah.. il mio consiglio è di pensare db indipendent, cioè non pensare se 
è più o meno lungo sommare tanti record, pensa ad una struttura 
affidabile e flessibile.

Potrebbe anche darsi che ti chiedano delle funzioni di archiviazione che 
risolvono il problema, però il punto è non trovarti ad avere pere e mele 
e volerle sommare

Ciao

-- 
Domenico L.                             icq: 645 44 861

per stupire mezz'ora basta un libro di storia,
io cercai di imparare la Treccani a memoria... [F.d.A.]