File flat e database relazionale per applicazione desktop per singolo utente

Question

File flat e database relazionale per applicazione desktop per singolo utente

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

1

Quindi tengo traccia di tutte le mie finanze usando un documento Excel (e lo sto facendo da molti anni) ed è diventato piuttosto un dolore. Quindi per un divertente side-project voglio implementare qualcosa per gestirlo per me.

Inizialmente ho impostato utilizzando Entity Framework con un LocalDB per gestire il backend per me. Ma mentre refolo continuamente questa applicazione, sto iniziando a pensare che forse un file flat è molto meglio per le mie esigenze.

Vorrei essere in grado di apportare modifiche e tali modifiche non persistono finché non salverò lo stato con un Ctrl + S. Ad esempio, solo perché cambio le mie entrate in un anno futuro, non voglio che essere salvato nel database (mi consente di sviluppare scenari "what-if"). Sembra che questo potrebbe essere fatto con un database ORM / relazionale, ma ci sarebbero molti rollback.

Gli altri requisiti includevano circa ~ 500 transazioni di spesa all'anno, diverse transazioni di investimento, ~ 50 transazioni di reddito, ecc. Quindi dopo 5 anni di utilizzo sto osservando 7200 transazioni che devono essere memorizzate.

Quindi, osservando i miei requisiti con i due grandi è il numero di record e di rollback rispetto al commit nel database, un file flat ha più senso? Inoltre, come decidere tra file flat e un database completo? Infine, questo sarebbe per il mio uso personale, quindi la concorrenza di rete, più utenti, ecc. NON dovrebbe essere un fattore.

design database

posta keelerjr12 21.04.2018 - 13:43

fonte

3 risposte

Leggi altre domande sui tag design database

Come rappresentare / indirizzare il contenuto in tipi mime multipli / diversi / impilati? Contenuto di Project Wiki

score 1 · Answer 1

Ti consiglierei di continuare a migliorare il tuo progetto. Sono certo che un giorno riuscirai a raggiungere il tuo obiettivo (cercare di motivarti). Ok, per la tua risposta ho fatto un sacco di supposizioni. Fammi sapere se ho torto, cercherò di modificare la mia risposta.

Soluzione: (assumendo) Dopo ogni transazione, stai accettando le tue modifiche. (Suggerimento) Invece di impegnarsi, prova a mantenere la tua sessione e prova ad apportare modifiche nelle tabelle #temp. La bellezza di questa tabella è che vengono eliminati non appena la sessione è finita. Ora ogni volta che esegui la tua applicazione, crea una copia di tutte le tue tabelle in #Temp (puoi usare un nome migliore di Temp)

(assumendo i nomi delle tabelle)

SELECT * INTO #Temp1 FROM Investment
SELECT * INTO #Temp2 FROM Transaction
... (All the other tables you have)

(qualcosa di simile a questo) Ora quando si apportano modifiche dal front-end, l'applicazione dovrebbe utilizzare la tabella temporanea per salvarla nella tabella temporanea. quando si è sicuri di volerlo salvare nel database, copiare la tabella Temp dalle tabelle originali. E commetti.

Suppongo qui di avere uno schermo con alcune caselle di testo e un salvataggio & un pulsante di annullamento. Ogni volta che apporti delle modifiche, premi il pulsante Salva, mostra l'output e salva i dati nel database. È possibile avere un pulsante di analisi che valuterà l'output utilizzando i dati nella tabella temporanea e se si desidera salvare fare clic su Salva. Salva copia i dati dalla tabella Temp alle tabelle originali. E nel pulsante Annulla puoi cancellare la tabella temporanea in modo esplicito o terminare la sessione e tornerai ai tuoi dati originali (come il rollback che fai adesso [assumendo di nuovo]).

Se non sei un fan di Temp Table allora puoi usare le tabelle tradizionali ma non andranno via dopo aver terminato la sessione, quindi devi cancellarle esplicitamente su cancel. Puoi anche troncare la tabella (quindi non devi eliminare la tabella, riutilizzare la tabella).

Spero che questo possa risolvere il tuo problema. Buona fortuna.

score 0 · Answer 2

Le banche dati memorizzano i nostri dati in questo modo (modello relazionale) che ci rende facile interrogarli usando uno standard (dal 1986), universale , documentato e lingua testata : SQL

Un database è [a] file (s) più il sistema di gestione dei dati.

Se per qualche motivo i tuoi non si adattano bene al modello di relazione puoi utilizzare un alternativo formato (come un non -file database o XML) o trovare il proprio proprio . Quest'ultimo richiede che anche venga fornito con il sistema di gestione dei dati appropriato (ad esempio una API ).

Ad esempio, Thunderbird (il client di posta) utilizza Mbox per archiviare tutti i messaggi come testo normale in un singolo (piatto ).

Oh, BTW, usare un enorme ORM come EF in un divertente side-project probabilmente sarà un overkill.

score 0 · Answer 3

L'entità può essere utilizzata anche per chiamare stored procedure. Puoi sfruttare il framework per i tuoi semplici metodi CRUD e fornire procedure con commit / rollback appropriati. I file flat vanno bene se stai facendo qualcosa come un POC o per testare, ma se hai intenzione di rendere scalabile l'applicazione, un database sarebbe il percorso preferito. I database relazionali tradizionali potrebbero essere sostituiti con quelli non strutturati. Se hai a che fare con file che potrebbero avere un numero casuale di colonne e definizioni, usare un database non strutturato come Firebase o MongoDB sarebbe una buona alternativa.