[basi di dati] prestiti/debiti in 3 soluzioni

[dogeht]

l'utente ha un salvadanaio e vuole tenere sotto controllo i PRESTITI e i DEBITI.

vuole sapere QUANTO HA DATO/HA PRESO vuole sapere A CHI e DI COSA SI TRATTA.
Inoltre si deve tener traccia dello STATUS del prestito/debito: cancellato, riscosso, in essere.

Ho diverse soluzioni:

a) faccio due tabelle distinte

PRESTITI ( id_prestiti, causale, importo, achi, status )
DEBITI ( id_debiti, causale, importo, achi, status )

b) creo una tabella per le voci in comune e le due tabelle che sfruttano la prima

MOVIMENTO ( id_movimento, causale, importo, achi, status )
PRESTITI ( id_prestiti, fk_movimento )
DEBITO ( id_debito, fk_movimento )

c) creo una sola tabella, con una voce che mi indica se il movimento e' un debito o un prestito

MOVIMENTO ( id_movimento, causale, importo, achi, status, tipo )

---------------------------------------------------------------------

Le operazioni su questi dati sono:

- inserimento di una voce ( 5 al giorno )
- modifica di una voce ( 0,2 al giorno )
- visualizzazione divisa di debiti e prestiti ( 30 al giorno )

---------------------------------------------------------------------

Scritto così, il problema, offre come soluzione più spontanea la soluzione a) poiche' l'operazione più frequente e' la visualizzazione suddivisa nelle due voci.

QUELLO CHE MI PREOCCUPA E' L'ESTENDIBILITA'.
ossia, in futuro, una rappresentazione di tipo a) sarà vincolante?
in quale maniera?
esistono altre soluzioni che non mi sono venute in mente?


grazie per la sopportazione...

[andr3a]

# dare / avere
TIPI (id_tipo, testo_tipo)

# acquisto / vendita / prestito / altro
CAUSALI (id_causale, testo_causale)

# cancellato / riscosso / in essere
STATI (id_stato, testo_stato)

# chi è (anagrafica contatti)
UTENTI (id_utente, nome, cognome ... dati_anagrafici ...)

# quando, quanto, tipo movimento, causale movimento, stato movimento, utente
MOVIMENTI (id_movimento, data_movimento, importo_movimento, id_tipo, id_causale, id_stato, id_utente)



in questo modo hai una gestione ottimizzata per fare reports statistici, avendo una tabella senza campi varchars per i movimenti (rapidissima)
Hai inoltre la possibilità di cambiare "tutto senza modificare niente", tutto riferito alle diciture (o dati cliente o altro), niente riferito allo storico dei movimenti


non so è la soluzione migliore ma probabilmente è quella che avrei adottato io soprattutto per il discorso estendibilità o riutilizzo (anagrafica o altro)


[edit]
io aggiungerei anche una tabella STORICO, per avere lo stato dei tempi tra una modifica dello stato di un movimento ed un'altra (quando è stato fatto il prestito, quando è stato riscosso)

[dogeht]

quindi la tua soluzione e' la c) ossia un'attributo che mi indichi la tipologia del movimento.
giustissimo il discorso del creare relazioni d'appoggio ( avevo omesso per semplicità )
bona l'idea dello storico...eh già, in questo modo posso ricostruire la storia dei movimenti e meglio ancora, ricreare situazioni antecedenti il momento attuale ( punto critico! ) GRAZIE!