Jump to content
  • Advertisement
Sign in to follow this  

[.net] What database should I use? (C#)

This topic is 4406 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello! I am trying to choose database for my online game server. To choose however I need knowledge about the different technologies and I don't have time to invest in all technologies to see if they are suitable. Here are my needs: 1) NO SQL - I don't want to protect myself against SQL injection 2) Just connected to a single database file on the harddrive that I can create in the program 3) Simple, easy, lightweight and fast write access - no advanced queries, just to make the world persistant I first started with ADO, but it just seems too complicated for my needs and I seem to have to use SQL for everything My next thought is DAO? Maybe better offers for just making my world persistant? I won't be reading anything from the database during the run, I will only read at startup but I will constantly write to the database to make sure that the world stays persistant in case of server crashes or updates. Thank you in advance!

Share this post

Link to post
Share on other sites
Your question is not quite clear. You're mixing databases and middelware.
First you should determine the requirements more. Think of number of concurrent users, money, speed, amount of data, throughput etc.

As for your state requirements:
1) The best way to prevent SQL injection is using Stored Procedures or Functions. Most other options require more client code.
2) Most databases allow the creation of the database file during runtime however you might want to reconsider that because when there is a flaw in your app you might end up with loads of database files. And you might not want to allow the internet account to create files to be a bit more on the safe side...
3) That all depends on the complexity of your world. Advanced queries are not a result of the database but of your datamodel. (Or bad writing...)

DAO, RDO, ODBC, OLEDB and ADO are middleware technologies that allow access to databases. These are not databases. ODBC, OLEDB and ADO are pretty current whereas DAO is 'old' technology.

Considering your final remark, you might not even need a database. Look up serialization which might allow you to simply dump and restore. There are several ways of using Serialization in .NET the most staight forward way is using the XmlSerializer


[edit] Hmmm just re-read... constantly writing to the database invalidates serialization as a serious option.

Share this post

Link to post
Share on other sites
1) What kind of data will you be storing? Does the user even have any means to enter data that will be directly passed to the database?

If you're looking for a serious database SQL is pretty much the way to go, no matter if we're talking oracle, mysql, sql server etc. And it comes in pretty handy if you want to look up data "by hand".

There are ways to protect yourself from injection, you should be able to find some decent answers on google. Stored procedures is one of those.

2) Why limit yourself to one file that "you" create? It's the job of the database server to maintain the files, you should never have to worry how the data is stored physically. All you care is about that you can store and retreive data as fast as possible.

3) A plain file is maybe faster than a db when it comes to write access, most databases are optimized for read access (indices etc.). But this may prove more trouble in the end and you might be limiting yourself in the long run. What if you suddenly find out that reading some data during runtime is not so bad an idea afterall?

And like the others already pointed out: SQL is a query language, not a database. It's a means of manipulating data that is stored in a database. ADO etc. are pretty much "wrappers" that hide some (or all) of the complexity of plain SQL. And as is with all wrappers they also limit what you can do with the data in one way or another ;)

(I'm pretty much a DBA right now, I've written more 'lines of code' in T-SQL lately than in any other language so my view may be a bit biased.)

Share this post

Link to post
Share on other sites
You don't necessarily need to use stored procedures (sprocs) to avoid SQL Injection. For simple projects, or where portability between databases is an issue, avoiding sprocs can be a good idea.

Instead, use parameterized queries. I'd go so far as to say don't ever, ever, insert user-supplied strings into an SQL query directly - even if you've carefully escaped everything out. It's far too easy to miss something (for example, some databases will accept ' from various unicode pages to let you do an injection attack).

How does one parameterize a query?

Say you want to do a simple SELECT, to find everyone who has the username Bracket:

SELECT id FROM users WHERE username='Bracket'

Bracket is supplied from a form in your program. The really unsafe way to do this would be: string SQL = "SELECT id FROM users WHERE username='"+username+"'";
You can make this a bit safer with various bits of safety code... or you can just let ADO and the database driver guaranty safety for you. For SQL server, it would look something like this:

SqlConnection cnn = new SqlConnection(connectionString);
try {
SqlCommand cmd = new SqlCommand("SELECT id FROM users WHERE username=@username", cnn);
SqlParameter param = new SqlParameter();
param.ParameterName = "@username";
param.Value = username;
string result = cmd.ExecuteScalar().ToString();
} finally {

Share this post

Link to post
Share on other sites
Just wanted to bump what Bracket posted regarding SQL injection, as it's a very important, and grossly overlooked, topic. It's very simple to avoid in .NET, and the approach that has been outlined in the above post, is exactly what I use for the same purpose.

For those who aren't aware of the damage potention of SQL injection, read this article.

Share this post

Link to post
Share on other sites
The fact that I mentioned stored procedures isn't just because of SQL injection. In a professional/enterprise environment with a large amount of concurrent users, stored procedures/functions have several extras that should not be overlooked.

1. Stored procedures are faster (when written well) because the server will have to parse and 'compile' the sql strings in the above examples first whereas stored procedures are already check and compiled.
2. Stored procedure function as an extra layer of abstraction, when (not too big) changes happen to the database schema the stp's interfaces remain the same.
3. Stp's have their own authorization, so security might benefit also.
4. Stp's might easily be extended with logging or tracing.
5. Only dba's need to know the schema and queries, programmers just need to know the Stp interfaces.

Some games are bigger than some enterprise apps so considering enterprise tricks isn't that bad...


Share this post

Link to post
Share on other sites
I agree with ernow. IMO you should always use sp's everywhere in your code, for good practice. There should be no SQL in your code. IMO the advantage of just having an added layer of abstraction alone makes it worth it.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!