If I'm not going to be saving data into an SQL database, where should I be saving it?

I'm making an encyclopedia program of sorts similar to RAWR for World of Warcraft. I'm not going to be saving data de an SQL database, but I've been conditioned so hard to always do this when I'm sure there are alternatives for these lighter case uses.

For example, my p开发者_开发知识库rogram will have no creation of new data via user input, nor deletion of data via user input. Just a program that will display information that I code into it. Nothing more, nothing less.

Where should I save these things? By save I mean, store them for deployment when I release the program.

I'm mostly going to be saving just string variables and some videos/animation (see my other question)

Thanks for the help SO. As always, you guys rock!

What's wrong with a database for static data? No data is static, with a DB your administrative/design program for creating the data package will be much easier if you used at database. If you store it in flat files do you really want to be writing the query logic to decide how to find the data or just issue a simple SQL query?

Use System.Data.Sqlite it lets you use an embedded database, a single data file with no server process. This is an extremely popular database, I'd be willing to bet that you interact with it daily. In addition it supports all the wonderfully RAD features in Visual Studio for designing and interacting with your data.

What's wrong with the good old filesystem?

You simply create a subfolder under your application folder and in your code always reference files within this subfolder by using a path relative to the application folder. eg.

string imagePath=Path.Combine(Environment.CurrentDirectory,"SubFolderName\\picture.jpg");

I've used SQLite myself and love it, but even it may be overkill for your needs as you don't say you need to perform many query operations.

Also, a relational database such as SQL Server / SQLite is not really ideal for storing binary data. They definitely can, but that is not what they do best as they can run into scaling issues.

If you have a lot of binary files such as images, music, video etc, then my first choice would be the filesystem.

Deployment is as simple as putting all required resource files in the subfolder and then placing the subfolder in the application folder.

Another option would be to store your files as embedded Assembly resources. This could be inside the main application executable, or in a separate dll assembly if you have larger files. You say the user will not be adding or deleting files, so this is a viable option.

My answer depends on exactly how much data you are talking about. From a purely design perspective, you should always separate your data from your application logic. So, you want to have an external data file. But, if you don’t really have that much data and it is relatively static then you can just put it in an XML file and use Linq to XML to query the data. Take a look at the XDocument class.

That being said, databases do generally make your life easier, especially if you get a good object to relational mapping tool or an object database. I would recommend that you look into using something like SubSonic SimpleRepository to put your data in a SQLite database. Or, even better, take a look at using a pure object database like DB4O!

Either xml or binary files would be my suggestions

My first thought is XML (preferred) or binary like Mark Ewer and yetapb were suggesting. The SQLLite suggestions sound pretty good as well.

Another option is an Excel spreadsheet using the OleDb provider. You would use SQL statements to read and write the data. If you go the Excel route, know that there are a few quirks to get used to such as: 1) The way you specify which sheet in the workbook you're referencing (analogous to how you reference a table in SQL + a dollar sign and some brackets). 2) If you have a column with only text, but one cell has a number OleDb will hiccup with an exception unless you massage the data a little bit. I know it sounds strange, but this is just a heads up.

I'm sure there are some other minor quirks to get over when playing with Excel from .NET but I've only done it in the real world twice (although a ton of data was involved both times). I definitely wouldn't recommend it for an enterprise environment.

I would suggest storing the multimedia in your file system whichever way you go. Then just have the data records whether they be in SQL, Excel, XML, or binary point to the filename. It will make data management much easier for you.