Posso chiederti qualche delucidazione?

Originariamente inviato da eumene

Punto 1: Entrate/Uscite.
Più che la tipologia, la cosa che distingue davvero un'entrata da un'uscita è il segno del valore!
Se ci pensi le entrate sono sempre positive, mentre le uscite sempre negative!
Ti suggerirei di non utilizzare alcun campo "tipologia" ma di inserire i valori con segno, questo per 2 motivi:
[list=1][*]Non perdi la funzione che richiedevi. Se hai scelto di usare MySql e ne sei sicuro, sappi che MySql (come tutti i DBMS) offre funzioni anche complesse da usare nelle query. Per esemprio, immaginando che la tua tabella "movimenti" abbia un campo "valore", per distinguere entrate da uscite basterebbe "SELECT valore, IF(valore>=0,'entrata','uscita') FROM movimenti". Se usi le VIEW poi una query del genere la puoi anche memorizzare in una vista appunto [*]Ottieni un'informazione in più in modo veloce: il SALDO. Essendo tutto nella stessa colonna valore (es. prima) una semplice "SELECT SUM(valore) AS saldo FROM movimenti" automaticamente di darebbe la somma algebrica dei valori, aggiungendo e sottraendo in funzione del segno. Pensa che questa query, con un where su altri campi, potrebbe darti il saldo dei movimenti di un dato periodo oppure il conto legato ad un cliente/fornitore[/list=1]
questa è un'ottima cosa, non sapevo di poter ottenere il saldo così facilmente, quindi sicuro farò così.

Punto 2: Mittente/Destinatario.
Qui la cosa è un po' complessa.
Prima di tutto devi distinguere 2 cose: il destinatario/mittente del movimento non implica la causale dello stesso, cioè un uscita per la banca (purtroppo) non è detto sia sempre per il mutuo.
Io direi di prevedere i campi "soggetto" (mittente/destinatario deriva dal segno del valore) e "causale" (descrizione del movimento).
La causale è ovviamente varchar o text (se scrivi tanto) mentre il soggetto potrebbe essere di 2 tipi:
[list=1][*]Riferimento (id) a tabella anagrafica esterna: è sicuramente la cosa più giusta in quanto crei una relazione tra le tabelle e separi per responsabilità. In anagrafica ci saranno dati (tel, email, ecc..) che non sono legati ai movimenti, ma di implementazione più complessa[*]Varchar dove inserire solo il nome del soggetto. Semplice da realizzare, ma scarsamente utile soprattutto se vorrai corredare di altre info il soggetto (e già lo fai)[/list=1]

Tutte le 2 soluzioni, cmq, permetterebbero di creare nel form il menù a tendina di selezione del soggetto: la prima con una select sulla tabella anagrafica, la seconda con una select distinct(soggett) sulla tabella movimento.
La cosa complessa però è che, a volte, dovrai gestire una doppia operazione in un solo form: l'inserimento del movimento e l'inserimento del soggetto (un nuovo fornitore, un nuovo cliente, ecc...)
Per tale motivo ti suggerirei di utilizzare una select per lo storico + un campo testo per il nuovo soggetto e lato server gestire il caso in cui, se il dato "soggetto" è inviato dal campo testo (es campi "soggettotxt" e "soggettoselect") allora, prima di inserire il movimento, inserirà il soggetto nell'anagrafica.
Questo flusso vale solo per il caso di tabella referenziata, in quanto con la soluzione distinct ti basterà inserire il nuovo movimento associato al nuovo soggetto e automanticamente troverai il nominativo nella select dei soggetti (mi sa che non sono stato molto chiaro qui)
Cmq io sono per la tabella referenziata
Dunque, considera che io una cosa simile la faccio già coi clienti nella parte di inserimento dei preventivi, ovvero:
Menu a discesa con elenco clienti usando l'id_cli, se poi non è presente, link al form di inserimento anagrafica.
Non è sicuramente ottimale perchè faccio fare il doppio passaggio in due pagine diverse (difatti pensavo di studiare un sistema che mi permettesse di aprire in un pop-up la lista clienti, magari divisa x pagine per poi una volta selezionato in questo pop-up, mi riportasse il valore alla pagina di prima), però questo mi consente di avere le anagrafiche complete di tutti i dati ed evitare di avere inserimenti "sporchi", tipo solo il nome ma niente numeri di tel, o p.iva eccetera.
Ecco, la stessa cosa vorrei farla per la gestione dei mittenti/destinatari, quindi credo che debba solamente ottimizzarne la gestione, che al momento è molto "semplicistica", con quell'ipotesi di pop-up che ti dicevo prima.

Punto 3: Data/Ricorrenza movimento
Ti stai infilando in una cosa molto complessa!!!!
e questa è l'unica cosa che sapevo di sicuro

Sicuramente il movimento deve avere una data, non ci piove, se non 2 addirittura: data dell'evento che genera il movimento e data della reale movimentazione di cassa (es: compro oggi un televisore (data evento) che pagherò tra 30 giorni (data uscita di cassa), oppure pagamento rata del finanziamento (data uscita di cassa) per l'acquisto dell'auto (data evento)), ma sto veramente esagerando!
Lasciamo solo la data di movimentazione cassa.
Questo l'avevo pensato, difatti volevo creare due campi data, di cui uno nascosto e con l'opzione "on update current timestamp", proprio per distinguere la data di inserimento (cioè quando premo il bottone inserisci prende la data e l'ora corrente) dalla data del movimento.
Come la vedi?

Per quanto riguarda la ricorrenza del movimento mi sa che devi un attimo ragionarci un po'.
Dal punto di vista analitico la tabella dei movimenti è un'entità statica (i movimenti non hanno una vita ma quando sono generati muoiono anche) e consuntiva (tracci il movimento quando è avvenuto, o poco prima).
Quello di cui parli tu è uno scadenziario, che ti aiuti a seguire i tuoi pagamenti.
Fino a qui niente di strano, stiamo solo dicendo che il modulo ha un altro nome.
Ancora non è il movimento che è ripetuto nel tempo, ma l'evento scatenante (rata mutuo) genera più movimenti nel tempo.
Sarebbe semplice dire che ogni movimento è un evento, ma nella realtà le cose sono un po' più difficili.
Un esempio veloce: immagina di essere riuscito a creare tanti movimenti in automatico ciclati sul tempo, ok? Ora pensa di dover cancellare un movimento, potrebbe capitare no? Ok, ne cancelli solo uno? Cancelli tutti quelli che seguono? Cancelli tutti i movimenti dello stesso evento? Ok, ma come distingui poi tutti i movimenti dello stesso evento se non gestisci l'evento in modo differente?

Per semplicità stabiliamo che il primo movimento di una catena è anche l'evento.
Un movimento singolo sarà una catena con un solo elemento!
Io farei così:
[list=1][*]La tabella ha un campo evento e per ogni movimento tale colonna assume il valore dell'id movimento padre della catena. In generale id ed evento saranno uguali se non nei casi di movimenti ciclici, dove i movimenti derivanti farebbero riferimento al movimento padre[*]Nel form di inserimento movimento aggiungere dei campi per gestirne la ciclicistà: data inizio ciclo (data primo movimento immagino), data fine ciclo, nuomero ricorrenze e tipo ricorrenza (per gestire da "ogni giorno" a "12 anni" - tipo ricorrenza potrebbe essere un menù a tendina con "giorno","mese","anno")[*]Quando invio i dati dal form, il modulo si accorge che se ho programmato un evento ciclico e, in quel caso, sfruttando un ciclo da data inizio a data fine a passi di ricorrenza, inserisce tanti eventi quanti ne risulteranno necessari, facendo attenzione di valorizzare la colonna "evento" con l'id del primo movimento della catena.[/list=1]

Se tutto funziona dovresti ritrovarti automaticamente tutti i movimenti inseriti nel database.
A quel punto potrai facilmente distinguere movimenti della stessa catena attraverso il valore della colonna evento e casi di operazioni con effetto a cascata (come la cancellazione o la modifica del valore della rata) potranno essere gestiti.
Dunque, se ho capito cosa vuoi dire...anche qui è già quello che faccio con gli articoli dei preventivi, ovvero... ad un id_preventivo, c'è associato un id_dettaglio_preventivo, proprio perchè posso avere N articoli presenti.
difatti l'idea che avevo era di riportare questa cosa anche nelle scadenze, per avere appunto un evento "padre" e le varie ricorrenze gestirle come "figli" di quell'evento.
E' questo che intendevi?

Lo so, non credo di essere stato limpidissimo, ma è un po' difficile dare una soluzione ad un quesito un po' complesso solo attraverso un forum.

Spero cmq di esserti stato utile

Meglio di così non potevi fare, grazie ancora

Fabri