12

I'm working on a small project (not production) where I'm needing to store enough data that something like a CSV would be inefficient to process and an SQL/MySQL server would be too much. Does .Net have any way to efficiently store several entries of data with the ability to query without having to manage and connect to a server rather loading and processing a single file.

Improve this question
8
  • If you already have a database server up and running making another database on there is pretty trivial. If you are only using the data maybe you could consider Access.
    – Brad
    Jul 2, 2013 at 19:08
  • @Brad this is just a personal project and I don't currently run any database servers at my home. Your suggestion of Access maybe exactly what I'm looking for.
    – David
    Jul 2, 2013 at 19:12
  • 4
    I'm not a fan of Access, but I'll grant it may the right solution sometimes. Have you considered Object Serialization? Just create an object & write it to a file. (The object could be a List<foo>)
    – Dan Pichelman
    Jul 2, 2013 at 19:16
  • Are you wanting these to persist or do they only need to be in-memory?
    – Richard
    Jul 2, 2013 at 19:21
  • 1
    @David: 4000 entries - so few? Why not hold them all in-memory? If you just need an in-memory database to make some queries, without any administrative tools, a dataset with some datatable (persisted to a file) may be enough for your needs.
    – Doc Brown
    Jul 2, 2013 at 20:30

4 Answers 4

Reset to default
15

There are a few alternatives, in no particular order:

  1. All versions of (paid?) visual studio come with SQL Server Express installed. You can use that.
  2. (Ugh) XML files
  3. SQL Server CE (basically, local SQL via file)
  4. SQLite

More ideas here: https://stackoverflow.com/questions/3639846/what-is-a-good-embedded-database-to-use-with-c

Improve this answer
6
  • I really want something that is totally self contained in a single executable, no DLLs and no third party software. Are any of the above, except XML, able to fit these needs?
    – David
    Jul 2, 2013 at 19:38
  • You can embed the dlls in your executable maybe.
    – Sklivvz
    Jul 2, 2013 at 19:39
  • Well I guess the most important part is no third party *services such as MSSQL/MySQL would #3 or #4 fit that
    – David
    Jul 2, 2013 at 19:42
  • I don't remember if SQL CE has a separate runtime or not. SQLite doesn't, but it can be a little tricky to set up with a .NET project.
    – GalacticCowboy
    Jul 2, 2013 at 19:50
  • 3
    I would add that LocalDB is an option. See this answer: stackoverflow.com/questions/9655362/…
    – Andy
    Jul 2, 2013 at 20:59
4

In addition to the options Sklivvz offered, don't be afraid to venture outside of the SQL realm and use an embedded object-oriented database engine, such as Sterling or DB4O.

They offer the advantages of being small and file-based, embeddable into your application, but are also very fast and easy to program to.

Improve this answer
3

SQLite would be your best option.
As written on their site:

SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine.

Seems really what you're looking for!

There's even a Chocolatey package if you're too lazy to download and install it yourself!

Improve this answer
3

ADO.NET can serialize to XML and has almost all of the functionality of an RDBMS. (Well, the cheap ones, anyway.)

I know it's "Old" and looked down on, now, but ADO.NET works really well for exactly what you're describing. It even does a pretty decent job of tracking non-committed changes.

It may be "Old," but it's certainly not "Busted." It's got a fairly heavy memory footprint, though, so your call on that. 4000 records won't be an issue.

Improve this answer
3
  • could you elaborate on "heavy memory footprint"?
    – David
    Jul 2, 2013 at 22:45
  • @David - It means that the entirety of the dataset would be held in memory, and not just the records you return from a query. If you had a database of 4 million records, holding it all in an ADO.NET dataset would be a serious draw on resources, whereas a "Real" RDBMS would hold it on a disk until you queried a subset of them. 4000 records is a small sneeze in memory usage, so I wouldn't worry about it.
    – Wesley Long
    Jul 2, 2013 at 23:19
  • +1, I think this is the best option, for this requirements even something small as SQLlite seems to be much effort.
    – Doc Brown
    Jul 4, 2013 at 10:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.