i have a question about storing data for a desktop application, if i'm to deployed an application without a MS SQL database, how could i facilitate the retrieving/storing of data. I know i can also serializes the data objects into a file (such as XML file), is there any other more efficient or effective way?
views:
241answers:
5
+4
A:
SQLite does very well as an embedded database. Even has .NET/Mono bindings available.
Ignacio Vazquez-Abrams
2010-02-11 04:29:58
awesome, thanks.
aggietech
2010-02-11 04:31:52
+1
A:
There are a variety of questions that one would ask to approach answering your question. For the purpose of this answer, I'm going to assume:
1) Limited amount of data needs to be stored. 2) Built-in capability (no third party or database requirement).
The most convenient, built-in (intrinsic to the base .NET installation) is a DataSet - specifically, a typed DataSet.
You can add an indefinite amount of tables and data to your DataSet (limited by available memory) and easily save and load the data from disk. DataSet's easily serialize to schema-bound Xml data.
Michael
2010-02-11 04:33:23
@Michael, yes it's going to be limited amount of data but i would like to by pass the serialization/XML route if possible.
aggietech
2010-02-11 04:35:49
Am I to understand that you want to save it to binary instead? I guess I'm trying to understand how you want to persist the data on the file system.
Michael
2010-02-11 04:43:54
+1
A:
I don't think you should be asking which is the "best" way, but which is going to be the best way for YOU.
When you say you can't have a database, I assume you mean the application needs to be stand-alone but could use a local database file? If that is so and you estimate large volumes of data storage will be needed, then you might find you'd like to use one of a number of compact local database products. SQLite and InnoDB come to mind for example.
If you are only going to store small amounts of data, an XML or simple binary file might be better for you, as it would reduce your application footprint, and would remove a dependency on a 3rd party product. We sometimes (and I stress very rarely!) still use the classic INI file because it is well supported in code, and results in extremely compact code.
As to efficiency and effectiveness, that all comes down to how you decide to go about implementing your data access. Granted, the type of database you use has an impact, but you also have to support whatever it is that you implement, so it would pay to look into how the database API is defined and documented, whether it has an active community for support, etc..., and choose the one you feel most comfortable working with.
S.Robins
2010-02-11 04:49:47
+1
A:
If you are on Windows and need to query data in a simple way, consider the built-in ESENT database engine (http://blogs.msdn.com/windowssdk/archive/2008/10/23/esent-extensible-storage-engine-api-in-the-windows-sdk.aspx). CodePlex has a .NET wrapper which includes a PersistentDictionary class (http://managedesent.codeplex.com/) which works like a .NET dictionary, but is backed by a database file on disk.
Laurion Burchall
2010-02-12 02:27:27