Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 13
  1. #1
    Utente di HTML.it
    Registrato dal
    Oct 2007
    Messaggi
    26

    [Sql]Relazioni tra Tabelle

    Salve a tutti, dopo tanto tempo di inattività in questo settore ho deciso di dare una ripassata alle mie conoscenze in SQL/PHP e con mio rammarico, mi sono accorto che ricordo molto meno di quanto pensassi

    Quindi qual buon metodo per rinfrescarsi la memoria se non quello di mettersi subito al lavoro?
    Seguendo un esigenza quotidiana ho deciso di realizzare una piccola applicazioni in PHP per la gestioni delle entrate e delle uscite monetarie mensili.

    Ma veniamo al dunque, l'applicazione finita sarà strutturata nella seguente maniera:

    • 1 Pagina che mi consentirà di scegliere il tipo di operazione da fare (Inserimento_Accrediti,Inserimento_Spese,Riepilogo _Conto)
    • 1 Pagina per l'inserimento degli accrediti (che possono essere 1 o più al mese)
    • 1 Pagina per l'inserimento delle spese (acquisti o cose da pagare)
    • 1 Pagina che mi mostrerà il saldo attuale e la lista degli accrediti e delle spese di ogni mese (Ma questa la vedrò con più calma dopo).


    Ed ecco il mio primo problema:

    Le tabelle

    Ho pensato di sviluppare tutto su 2 tabelle:

    La prima chiamata accrediti con le seguenti voci

    codice:
    id_accredito
    tipo_accredito
    data_accredito
    accredito
    mese(bho)
    codice:
    Id_uscita
    data_spesa
    oggetto_spesa
    importo_spesa
    mese(bho)
    Adesso la mia domanda è

    Come metto in relazione le 2 tabelle? ed inoltre è il caso di creare una terza tabella ?

    Grazie anticipatamente per l'aiuto e mi scuso se ho sbagliato sezione

  2. #2
    Non è meglio se usi una singola tabella che potrai chiamare "Operazioni" con:

    • id_operazione (int)
    • oggetto (varchar)
    • data (varchar)
    • importo (float)
    • entrata (int 0/1)
    • uscita (int 0/1)


    Alla fine dei conti i campi sono gli stessi per entrambe le tabelle.
    Se è un entrata metti 1 su entrata e 0 su uscita.
    Se è un uscita metti 1 su uscita e 0 su entrata.

    Puoi filtrare le entrate, le uscite, ordinare per data (con la data il mese non serve) e non ti servono Join di nessun tipo. Se eventualmente le entrate sono sempre le stesse (Stipendio1,Stipendio2 ecc) puoi pensare di sostituire il campo entrata con id_entrata e joinarlo con una tabella tipo_entrata.
    ...il passato lo rimpiange chi non ha futuro...
    Lega LFA | Alessio Corse | a2area

  3. #3
    Utente di HTML.it
    Registrato dal
    Oct 2007
    Messaggi
    26
    E' un ottima soluzione anche se mi lascia perplesso... così facendo se in un futuro mi venisse in mente di aggiungere delle funzionalità all'applicazione aggiungendo maggiori dettagli alle operazioni dovrei ricominciare da capo no?

    scusa se la domanda può risultare un po banale ma devo proprio rientrare nella mentalità riflessiva adatta al tipo di lavoro

  4. #4
    Utente di HTML.it
    Registrato dal
    Oct 2007
    Messaggi
    26
    Nessun altro consiglio?

  5. #5
    Anche io ti consiglio di fare una sola tabella, ma non come ti ha suggerito lxn.
    Secondo me è più logico usare una colonna per le entrate ed una per le uscite (funziona un po' come la partita doppia che insegnano ai ragionieri).
    Io toglierei anche la doppia form (entrate e uscite) ed userei un campo di SELECT per scegliere il tipo di operazione.
    In base al tipo di operazione, imposti la stringa SQL, se andrà a popolare il campo entrata o quello uscita.

    Ergo, io strutturerei la tabella nel seguente modo:
    Codice PHP:
    id_operazione INT(5)
    causale VARCHAR(200)
    data DATE 
    entrata 
    (float)
    uscita (float)
    note TEXT 
    Nota che il campo data, l'ho definito come DATE, ma tutto dipende dal metodo che usi per inserire le date nel DB.

    così facendo se in un futuro mi venisse in mente di aggiungere delle funzionalità all'applicazione aggiungendo maggiori dettagli alle operazioni dovrei ricominciare da capo no?
    Puoi già pensare a delle altre applicazioni future?
    Se sì, allora puoi pensare di strutturare diversamente il DB, altrimenti, ti conviene pensarci due volte prima di complicarti la vita da subito senza neanche sapere se ti può servire altro.

    Una cosa non capisco.
    scusa se la domanda può risultare un po banale ma devo proprio rientrare nella mentalità riflessiva adatta al tipo di lavoro
    Cioè???

    @ lxn
    Mi spieghi perché un campo data lo segni come varchar, per cortesia???

    <ALCIO />
    Per cortesia: no PVT Tecnici
    ******* LINKS *******
    SRL
    MetalWave

  6. #6
    Originariamente inviato da alcio74
    Anche io ti consiglio di fare una sola tabella, ma non come ti ha suggerito lxn.
    Secondo me è più logico usare una colonna per le entrate ed una per le uscite (funziona un po' come la partita doppia che insegnano ai ragionieri).
    E' vero, anche se credo che a livello contabile non sia possibile registrare entrata e uscita sotto una singola operazione (ne so veramente poco )

    Originariamente inviato da alcio74
    @ lxn
    Mi spieghi perché un campo data lo segni come varchar, per cortesia???

    Errore mio. Il mio intento era di fargli inserire un timestamp.
    Funziona si con VARCHAR sia con INT comunque!
    ...il passato lo rimpiange chi non ha futuro...
    Lega LFA | Alessio Corse | a2area

  7. #7
    E' vero, anche se credo che a livello contabile non sia possibile registrare entrata e uscita sotto una singola operazione (ne so veramente poco )
    Beh... io sono un chimico, ma la partita doppia si fa così: due colonne distinte (dare e avere), le cifre tutte con segno positivo, poi la colonna dare si sottrae a quella avere.
    Ripeto, non sono un ragioniere, ma l'estratto conto della banca così è fatto!

    Errore mio. Il mio intento era di fargli inserire un timestamp. Funziona si con VARCHAR sia con INT comunque!
    Volevo chiarire.... non è che sto qui sul forum a fare il detective in caccia di errori, eh!
    La data si può salvare anche in un campo TEXT, se è per questo, ma indubbiamente usare tipi di dato coerenti per "stoccare" i dati, aiuta sotto molti punti di vista, nonché nelle performance del DB.
    Ho voluto precisare, perché ritengo che se qualcuno ha qualche difficoltà, trovare un aiuto in uno script con degli errori più o meno gravi, non è proprio il massimo!
    Detto questo, saluto entrambi!

    <ALCIO />
    Per cortesia: no PVT Tecnici
    ******* LINKS *******
    SRL
    MetalWave

  8. #8
    Utente di HTML.it
    Registrato dal
    Oct 2007
    Messaggi
    26
    Salve a tutti, rieccomi!

    In questi giorni sono stato molto impegnato e non ho dedicato molto tempo al mio progetto.

    Ad oggi non ho ancora creato il database ma in compenso mi sono dedicato alla costruzione dei form di entrata e uscita.

    Ecco qui il link del lavoro svolto fino ad ora:

    codice:
    www.gimisrl.it/Applicazione/

    Il database in un unica tabella continua a non convincermi

    Inoltre visto che ho realizzato così la struttura non saprei bene come far capire in un unica tabella se si tratta di un entrata o di un uscita

  9. #9
    Arifacce!
    Una colonna la chiami ENTRATE, una colonna la chiami USCITE.
    Di campo data te ne serve 1, di campo note pure.
    Non capisco dove siano le perplessità.



    p.s. Carino il menù ad icone e l'utilizzo di AJAX.
    <ALCIO />
    Per cortesia: no PVT Tecnici
    ******* LINKS *******
    SRL
    MetalWave

  10. #10
    Utente di HTML.it
    Registrato dal
    Oct 2007
    Messaggi
    26
    E se volessi aggiungere altre 2 voci?

    Vorrei aggiungere:
    In entrata
    Tipo di accredito (Bancario o Postale)
    Casuale accredito (Tipo di lavoro,visto che ne ho 2)
    In uscita
    Tipo spesa (Cioè provenienza denaro, posta/banca)
    e come riepilogo vorrei avere la possibilità di avere il saldo totale (conto banca+conto posta) e i 2 saldi singoli (posta e banca)



    Non ero convinto della soluzione unica perché ero sicuro di trovare qualche aggiunta da fare per strada!!!

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.