views:

128

answers:

4

I am just beginning to write an application. Part of what it needs to do is to run queries on a database of nutritional information. What I have is the USDA's SR21 Datasets in the form of flat delimited ASCII files.

What I need is advice. I am looking for the best way to import this data into the app and have it easily and quickly queryable at run time. I'll be using it for all the standard things. Populating controls dynamically, Datagrids, calculations, etc. I will also need to do user specific persistent data storage as well. This will not be a commercial app, so hopefully that opens up the possibilities. I am fine with .Net Framework 3.5 so Linq is a possibility when accessing the data (just don't know if it would be the best solution or not). So, what are some suggestions for persistent storage in this scenario? What sort of gotchas should I be watching for? Links to examples are always appreciated of course. Thanks in advance.

+1  A: 

It looks pretty small, so I'd work out an appropriate object model, load the whole lot into memory, and then use LINQ to Objects.

I'm not quite sure what you're asking about in terms of "persistent storage" - aren't you just reading the data? Don't you already have that in the text files? I'm not sure why you'd want to introduce anything else.

Jon Skeet
The persistent portion would be to store user entered data. Basically what the user (me) eats. :)
EBGreen
In which case it sounds like the persistent storage part is entirely separate from the rest of your question - loading the data from the flat file etc. You could use an embedded database, or full SQL server etc.
Jon Skeet
Yeah, I guess deciding whether or not to separate the data (user vs. text) was the real design question. I just wondered if I was going to have a DB anyway if I shouldn't just go ahead and load the text data into there and get rid of the text files altogether.
EBGreen
I'm a huge LINQ to Objects fan, and basically it's hard to go wrong with in-memory queries of a fixed, smallish data source :)
Jon Skeet
Thanks for the advice. I suspect that this is the way that I will go. I will leave the text files the way that they are and load their data into memory. I will use a DB for the user generated data.
EBGreen
A: 

I would import the flat files into SQL Server and access via standard ADO.NET functionality. Not only is DB access always better (more robust and powerful) than file I/O as far as data querying and manipulation goes, but you can also take advantage of SQL Server's caching capabilities, especially since this nutritional data won't be changing too often.

If you need to download updated flat files periodically, then look into developing a service that polls for these files and imports into SQL Server automatically.

EDIT: I refer to SQL Server, but feel free to use any DBMS.

Kon
Given the size of the file, it would be simpler to load it all into memory - then you can stick to simple and powerful in-memory operations. I'd always prefer that to database access, given the chance :)
Jon Skeet
A: 

My temptation would be to import the data into SQL Server (Express if you aren't looking to deploy the app) as it's a familiar source for me. Alternatively you can probably create an ODBC data source using the text file handler to get you a database-like connection.

Lazarus
A: 

I agree that you would benefit from a database, especially for rapid querying, and even more so if you are saving user changes to the data. In order to load the flat file data into a SQL Server (including Express), you can use SSIS.

DOK