Ciao Fabrizio.


La tua richiesta è abbastanza corposa.
Cercherò di risponderti per punti.

Innanzitutto una cosa deve esserti chiara: prima di pensare al db pensa a quello che vuoi fare e come.
So che lo hai fatto (l'hai scritto), ma non credere che per una data interfaccia/funzione esista sempre una sola implementazione. Mi spiegherò meglio più avanti portando alcuni esempi ai tuoi punti oscuri.

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]

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

Punto 3: Data/Ricorrenza movimento
Ti stai infilando in una cosa molto complessa!!!!
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.

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.

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