13

What should I use? I need to store data, and it only needs to be on the local machine. I will be storing all string variables, and in many columns.

What is the best? Would it even be a database?

Bloodyaugust
  • 2,463
  • 8
  • 30
  • 46

9 Answers9

13

I would recomend db4o, an object database engine. It's pretty straightforward and no server or installation is needed on the client. Another alternative would be SQLite. You can get the .NET provider here.

Edit

See db4o tutorial here.

Fernando
  • 4,029
  • 1
  • 26
  • 35
  • +1 for pointing out db4o. It's much simpler and natural than the others, since you don't need to handle connections and other stuff (just objects). –  Feb 17 '10 at 01:48
  • And this is done completely in C#? – Bloodyaugust Feb 17 '10 at 01:57
  • @Bloodyaugust - yes it is. You can check the source code at https://source.db4o.com/db4o/trunk/db4o.net/ – Fernando Feb 17 '10 at 14:22
6

SQL Server Compact 3.5 SP1 does not require installation (You just need to deliver the .dlls, although check the EULA if that's allowed) and is rather straight forward to use.

Michael Stum
  • 177,530
  • 117
  • 400
  • 535
5

I would recommend using sqlite, it's a very fast file-only, embedded-able, feature-rich, database. I have a lightweight ORM with C# bindings that abstracts and simplifies access to it. Here is a live web-service demo using sqlite.

Oh yeah db4o is a good choice as well which I also have C# database bindings for that supports C# automatic properties (as the default db4o provider doesn't) and other common data access scenarios.

mythz
  • 141,670
  • 29
  • 246
  • 390
3

You should look at SQLite if you're looking for an RDBMS or something like MongoDB if you're storing objects or similar.

Chris Conway
  • 16,269
  • 23
  • 96
  • 113
2

Why not SQL Server Express? It's even free.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • 2
    @Downvoter: what's the problem? SQL Server Express does not require, or even use, a network. – John Saunders Feb 17 '10 at 01:42
  • I didn't downvote you, but there are much simpler options that don't require a 84MB-500MB download and huge footprint. It provides more robust options, for sure, but this person just wants to persist a bunch of strings. – Chris Conway Feb 17 '10 at 01:52
  • I downvoted your answer by mistake; it's undone now. – Matthew Flaschen Feb 17 '10 at 01:53
  • @Chris: for the record, the 84MB is just the database, 172Mb for the management tools, 225MB for database plus management tools, and the 515MB is for everything, plus the advanced services (full-text search, Reporting Services). Also, he talks about strings, but "a bunch of columns". – John Saunders Feb 17 '10 at 03:36
  • 1
    @John: correct, 84MB is the size of just the database, but compare that to 500K and zero install of SQLite and you see a drastic difference. Deployment also becomes extremely easy as it could just be a copy and paste. And for the bunch of columns, SQLite can handle up to 32767 columns in a single table. – Chris Conway Feb 17 '10 at 14:48
  • @Chris: I didn't say SQLite is bad. I don't know about it. I did say that SQL Server Express is a free solution. And, small size isn't everything. – John Saunders Feb 17 '10 at 16:40
2

I would highly recommend checking out the serialization framework. It's not even close to the performance of a database, BUT, if you're not talking about a lot of data, it has about 100% less overhead. Serializing objects to a file in .net is child's play:

XmlSerializer serializer = new XmlSerializer(typeof(myObjectType));

using(FileStream stream = new FileStream("file", FileMode.Create, FileAccess.Write)
{
   serializer.Serialize(stream, myObject);        
}

That's it!

Reading back is pretty much the opposite. LINQ provides even more options. Again, this is not even close to a db in terms of performance, but I have seen many, many implementations wherein a database was extreme overkill for the amount of data being stored. Obviously, if you have a clear need to scale, etc, you'll want to plan for that. Right tool for the right problem and all that.

Jeff
  • 2,701
  • 2
  • 22
  • 35
  • Would you say that maybe 200 objects with 10 properties each is reasonable for serializer? – Bloodyaugust Oct 05 '10 at 06:24
  • Again, it depends on what you're doing but I think it's reasonable. The nice thing is that (depending on what "breaking" changes you can afford) you could always switch to a binary serializer, which has pros and cons as well. The pros of a binary serializer are pretty much entirely performance related and the cons are more type-related. I know there are people that vilify the XmlSerializer but I tend to use it if I can afford to just b/c you'll generally run into fewer problems in the long run. One other thing - consider using attributes instead of elements! – Jeff Oct 05 '10 at 19:36
0

check out memcache if you want extremely fast speed. But they don't write to hard drive, so you might still need other mentioned db if you want to store them across sessions. In my project, we use mongodb to buffer data and use memcache to buffer for mongo. So data will be retrieved from memcache first, if not found, try mongo. If still not found, we then get new data.

For windows and .net, look at here

Community
  • 1
  • 1
Grant Li
  • 973
  • 9
  • 8
0

If you're just looking to store a small amount of data in a fairly simple structure, and aren't going to be doing any complex querying, then consider an XML file. You don't need any additional software, and you can work with it easily using LINQ to XML.

Chris Fulstow
  • 41,170
  • 10
  • 86
  • 110
0

XML can instead of your requirement!

lzrckt
  • 17
  • 1
  • 3