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?
@Downvoter: what's the problem? SQL Server Express does not require, or even use, a network.
John Saunders
2010-02-17 01:42:48
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
2010-02-17 01:52:22
I downvoted your answer by mistake; it's undone now.
Matthew Flaschen
2010-02-17 01:53:42
@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
2010-02-17 03:36:04
@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
2010-02-17 14:48:19
@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
2010-02-17 16:40:35
A:
It depends.
How will you be using it?
Without more details, I might recommend XML, MDB, or SQLite.
SLaks
2010-02-17 01:37:38
+8
A:
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
2010-02-17 01:39:52
+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).
Augusto
2010-02-17 01:48:26
@Bloodyaugust - yes it is. You can check the source code at https://source.db4o.com/db4o/trunk/db4o.net/
Fernando
2010-02-17 14:22:17
+3
A:
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
2010-02-17 01:39:59
+4
A:
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
2010-02-17 01:40:01
+4
A:
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
2010-02-17 01:42:28
A:
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.
cxfx
2010-02-17 01:50:40
+1
A:
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
2010-02-17 02:01:51
Would you say that maybe 200 objects with 10 properties each is reasonable for serializer?
Bloodyaugust
2010-10-05 06:24:22
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
2010-10-05 19:36:07