Oggetto / i di raccolta dati in memoria vs database

Question

Oggetto / i di raccolta dati in memoria vs database

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

1

Ho un paio di domande sulla praticità dello sviluppo di un'applicazione WPF che carica i dati in memoria da un file di testo e quindi manipola gli oggetti risultanti anziché le transazioni con un database come SQLite. Più viste avrebbero binding sull'oggetto / i risultante / i in memoria. Perseguire gli aggiornamenti del file di testo sul disco potrebbe avvenire solo all'arresto dell'app.

Il dato è un registro di radioattività memorizzato come formato .adi. ADI è un formato testuale che memorizza i dati tabulari nelle stringhe, inclusi i nomi delle colonne e i loro valori. Le righe di dati sono terminate con un tag. Esistono numerose applicazioni che analizzano questi file .adi riga per riga in una tabella di database in cui vengono letti e modificati dall'app. L'intero database può quindi essere esportato in un file .adi in cui ogni record di tabella viene serializzato in una riga di testo nel file .adi. Molti di loro utilizzano una qualche forma di database come SQL.

Il più grande registro di cui sono a conoscenza è di circa 120.000 record, ma un utente tipico potrebbe raggiungere da 60.000 a 70.000 nella loro vita. Ogni record di dati può contenere fino a 30-40 colonne tra cui una combinazione di valori stringa, intero e datetime.

Sono interessato allo sviluppo di un'app in grado di gestire circa 100.000 di tali record senza l'utilizzo di una soluzione di database come SQLite o MS SQL. Un file di testo .adi di questa grandezza dovrebbe avere una dimensione inferiore a 50 MB sul disco. Quando l'app viene caricata per la prima volta, legge il file di testo in un oggetto per il binding a una griglia. Le modifiche verranno applicate agli oggetti fino all'arresto dell'app quando vengono persistenti nel file sul disco.

Un oggetto basato su un file di testo di dimensioni pari a circa 50mb rischia di essere problematico se l'app è in esecuzione su una macchina Windows semi-moderna con 4 GB di memoria di sistema?
Lo standard ADI include molte enumerazioni. Se stavo convertendo questo file standard in un database relazionale avrei numerose tabelle di ricerca che rappresentano le enumerazioni. Ma dato l'obiettivo di sviluppare senza la necessità di una soluzione di database esterna, sto pensando di memorizzare le enumerazioni come oggetti di classe in una libreria. Ho ragione nel ritenere che un dizionario o enumerazione hard-coded non occupi nessuno spazio di memoria finché non viene chiamato?

Grazie per il tuo aiuto.

c# sql database memory wpf

posta W4LKR 04.10.2016 - 03:33

fonte

3 risposte

Leggi altre domande sui tag c# sql database memory wpf

Il suffisso -Impl è una convenzione di denominazione legittima per un metodo Hook in Java? pagina php multiplo in una pagina php principale

score 2 · Answer 1

Is an object based on a text file approximately 50mb in size likely to be problematic if the app is running on a semi-modern Windows machine with 4gb-8gb of system memory?

Non l'oggetto stesso. Sono più interessato al modo in cui pianifichi di implementare l'interfaccia utente. Il design della griglia che proporrà richiederà molte, molte volte la quantità di memoria che richiede l'ADIF effettivo e non sarà esattamente user-friendly.

Am I correct that a hard-coded dictionary or enumeration does not occupy any memory space until it is called?

Puoi certamente rendere tali oggetti pigri. Tuttavia, ho dato un'occhiata alle enumerazioni e la quantità di memoria richiesta per loro è quasi certamente irrilevante comunque.

...without the use of a database solution such as SQLite or MS SQL

Ci sono molti validi motivi per cui quegli altri ragazzi hanno costruito le loro app su un sistema di database; ottieni un sacco di funzionalità gratuitamente. Avere tutti i dati di registro in un database lo rende improvvisamente utile per tutti i tipi di scopi, non ultimo dei quali è il filtraggio, la ricerca, l'ordinamento e l'interrogazione dei dati risultanti.

score 1 · Answer 2

Sono d'accordo con le altre risposte qui, ma voglio aggiungere un piccolo dettaglio sul motivo per cui creare tutto questo in-memory e persistere in un file può essere problematico.

Se stavi solo costruendo un'applicazione per visualizzare questi file, la creazione di un DB sarebbe probabilmente eccessiva. Ma vuoi fare delle modifiche e poi salvare tutto alla fine. Questo approccio è problematico:

Se l'applicazione si arresta in modo anomalo (il computer si spegne, l'utente lo spinge verso il basso, ecc.), tutte le modifiche dall'ultima volta che è stato aperto verranno perse definitivamente.
Se l'applicazione si blocca durante il salvataggio o presenta un bug nella routine di salvataggio, si corrompe il file e potenzialmente si perde l'intera cosa.

Ho avuto il dispiacere di lavorare con le applicazioni che salvano i cambiamenti in uscita e odio ciò su di loro. Considero un tale approccio una cattiva pratica. Per risolvere il problema con una progettazione di file, è necessario, come minimo, eseguire il backup del file prima di provare a scriverlo. Quindi sarà necessario essere in grado di salvare il file sia in modifica o lasciare che l'utente controlli quando viene eseguito il salvataggio. Salvare l'intero file potrebbe essere un po 'lento, ma i file non sono molto grandi, quindi potrebbe essere OK. Questa è la tua implementazione minima.

Se vuoi migliorare questo, però, dovresti essere in grado di aggiornare sezioni del file senza dover scrivere l'intera cosa ogni volta. Una volta arrivato a questo punto di sofisticazione, l'utilizzo di un database è molto più semplice rispetto alla tentazione di manipolare un file in questo modo.

score 0 · Answer 3

Se stai parlando di .NET, un singolo oggetto o collezione è limitato a 2 GB e non ottieni tutto ciò in quanto deve essere contiguo. Se è solo 50 MB su disco, dovresti essere OK.

Come ha detto Robert - se il tuo progetto è di visualizzarlo ALL in una griglia che sarà più memoria dei dati. Potresti voler ripensare a questo design.

È possibile utilizzare la raccolta e le enumerazioni per archiviare i dati in memoria.

Puoi cercare raccolte con LINQ.

Ho scritto una piccola applicazione in cui i dati sono stati letti da XML, manipolati in memoria e quindi riscritti in XML. Ma sarebbe stato molto più facile scriverlo come applicazione di database. I dati in XML erano un requisito.