C# Datastorage Question

[Lingering]

I am a reasonably experienced coder (mostly pre true OOP) and I am starting to play with C#/XAML (VS2013) and thus doing an application to get me used to things and how it all ticks, I am trying to work out the best way to:

1. Store data (XML, Database, resource c#, etc)
2. How then best to handle/manipulate the data (Should I be holding it in a collection or just calling it from its datstore?)

The data itself is in two different categories: Data which is used to populate ComboBoxes & Differing settings.. 

 

I hope this makes at least some sence.

[madknight3]

It seems to me the storage solution mostly depends on what you are storing. Can you give an example of the data you'll be storing and an estimate of how much data there will be?

[Lingering]

Most of the data is to fill Comboboxes and descriptions/examples with supporting numbers about 100 rows like this:

 

Revive, 1, 10, false, false, healers, "This skill allows a character to extend a Chant of Heal Wounds to every location on a single character, for no additional spell cards. The healing is location by location, not simultanious and the healer may choose what damage to heal first. Contact with any part of the target is sufficient but the Chant of

Heal Wounds cannot heal any location with a mortal wound, these must be healed seperately. The spell functions in all other ways as normal."

 

One of my other concerns is how if i go the database route does Visual studio handle files output on builds include all the database setup files needed as I expect it will be used on a few different machines.

[madknight3]

A database seems like the way to go. If the application is being run on a few different machines, will each use their own local storage (I assume with copies of the same data) or will you set them up to all use the same storage in a single location?

[Lingering]

Online SQL seems a good way to keep everything updated but that comes with its own issues could be fun to play with though.

 

Would you suggest I use SQL them or does MDF get any bonus points with local use?

Would SQL need to be installed separately with a local database or does VS & the .NET work its own magic?

[YellowDragon]

Well you can always write to a text file and easily access by creating your own key values for certain settings, this could give you the ability to change settings just like any normal config file in a game.

http://msdn.microsoft.com/en-us/library/8bh11f1k.aspx

For instance:

(AlphaShadeValue - 30)

 

Or depending on what you want for your back-end you could always integrate with a  database and have a  table just for settings in say a  MS access database, OLE DB would be good if you want to go this route.

http://msdn.microsoft.com/en-us/library/aa288452%28v=vs.71%29.aspx

[madknight3]

Hmm, others may have a better idea, but to me I would either do one of the following:

• Set up a local database like SQLite (there may be better options out there this is just one I know of). You should be able to package everything together, including setting up and filling the tables, so nothing extra should need to be installed by the user.
• Set up your database on a remote server for all your applications to share and access. If security is an issue, access the database indirectly through a server/web service so there's no direct connection to the database.

[Lingering]

Or depending on what you want for your back-end you could always integrate with a  database and have a  table just for settings in say a  MS access database, OLE DB would be good if you want to go this route.

 

 

When you say intergrated, is this build into VS outputs? Is that mdb s?

[rockking1379]

Well you can always write to a text file and easily access by creating your own key values for certain settings, this could give you the ability to change settings just like any normal config file in a game.

http://msdn.microsoft.com/en-us/library/8bh11f1k.aspx

For instance:

(AlphaShadeValue - 30)

Or depending on what you want for your back-end you could always integrate with a database and have a table just for settings in say a MS access database, OLE DB would be good if you want to go this route.

http://msdn.microsoft.com/en-us/library/8bh11f1k.aspx

Do not use access. Sqlite provides a damn .NET driver and is better than access

[YellowDragon]

When you say intergrated, is this build into VS outputs? Is that mdb s?

When I  say integrate, I mean implement or extend your original solution.

 

also yes its mdb

http://msdn.microsoft.com/en-us/library/aa288452%28v=vs.71%29.aspx

[YellowDragon]

Do not use access. Sqlite provides a damn .NET driver and is better than access

 

When all  you have  is a hammer everything looks like a nail. Truth be told there  are tons of ways to save data. I  just gave some  ideas off the top of my head.

[rockking1379]

When all you have is a hammer everything looks like a nail. Truth be told there are tons of ways to save data. I just gave some ideas off the top of my head.

Oh no doubt there are tons of ways to save data. Txt, csv, db, pure binary. But there was a piece of software I recently helped replace that used access and its access version was before office '03...we couldn't upgrade it bcuz the software wasn't compatible, with sqlite your database is the version that your driver was at the time you shipped it. So if you never update the driver then it never breaks compatibility and the only thing you gotta take between machines to retain the data is the file. Which I find very easy

[Ohio]

Agreeing with some of the other posters in this thread, I think your best bet is going to be a remote database with a webservice to interact with the database (if you are worried about the users access to the database) or just direct connections. 

 

In the System.Data.SqlClient namespace you can find what you need as far as connecting to a SQL database (you can also find the SQLLite implementation in the same System.Data namespace).

 

If you end up going with the open source MySQL solution, they have a connector that is VERY similar to the one in System.Data. 

 

Either way if you go with a database I have a nifty class I can provide you (if you're interested) for either MSSQL or MySQL that streamlines database access. 

[laxer]

There is no need to use SQL.

 

You can just read the files in and treat them as a gridview/dataTable

 

The only place a database would come in is if you wanted to store it online.

 

With the gridview/dataTable all you have to do is change the datasource to point at the DB instead of the file and you would be off and running.

[Ohio]

It seems like we're talking about a game here, or some form of game knowledge base, which would then (I assume) have the need to have everyone's client up to date with the latest game data. If he goes with a file for his storage, he would then need to have a central hub for all of the clients to validate against, or make some form of peer to peer system, which brings along its own risks. From what I can gather in this thread as far as what this application is going to be, I think a centralized database is probably the best bet. 

 

I suppose a better description of what is trying to be built here would help us dig into the best bet for this application . 

[Lingering]

Yea its effectively a hobby resource for a game (Live roleplaying) for helping people build characters, things shouldn't change too much, normally I would have used a database but i am failing to find some good end to end examples for me to learn how it works under VS.

 

Data manipulation is something that I am gonna need so SQL (or being able to use SQL style select comments will be useful as then I can query the database rather than having to push data into c# and manipulate it from there.

[Ohio]

I would suggest going with MySQL, as I assume you don't want to drop the cash for your own SQL Server install. MySQL hosting is also much cheaper than MSSQL. 

 

If you need any help with the actual database structuring and all of that, let me know. Here is a class I whipped up for you that will make talking to your MySQL databases very easy. It assumes you will be using stored procedures, however it does have a method for query strings. You'll need a reference to the MySQL data connector provided on their website. I had planned on making this more verbose, however something came up at work and I need to step away for a while, hopefully this is mildly helpful .

 

 

(Annnnd the forums did not like my code snippet for C#, If you are interested in the class I can find a way to make it not look like it just did.)

[Nuluvius]

NuGet (already integrated into VS) is your friend. I would also look to see if you can use the Entity Framework with whatever your choice will be. Generally though if you place it all behind an interface you can change it out later if you decide you need something different.