Database for 1st Commercial Game (Access, SQL, SQLite?) Help?

Started by
24 comments, last by ROBERTREAD1 17 years, 5 months ago
How about Postgres?.. (www.PostgreSQL.org)
It's very good, and have BSD license.. Meaning that you can use it for a commercial non-OpenSource proyect.
Advertisement
Quote:Original post by Erik S. Andersson
Quote:Original post by Anonymous Poster

Nobody NEEDS ADO.NET or .NET 2.0 Data Binding. For that matter nobody really NEEDS C# itself either. You can do things the "hard way" or the "old way" if you want to call it that.

Specifically the requirement for Data Binding revolves around creating the game editor which allows you to basically alter every aspect of the game. It is a lot easier to write and update this interface using data binding.


Of course you don't need anything in that sense, but the question was more if the requirement came from someone else or if it was a personal preference. Although I have no personal experience with ADO.NET/Data Binding I'd still say that it is highly unlikely that anything else is to be considered hard and antiquated. As far as I can tell you want to use your previous experience in SQL on the game which might be a good idea, but it might also make things more complicated than necessary. I'm genuinely curious, what about data bindings makes everything else look old and hard?


"Data Binding" is the association of object properties with control properties facilitated by a data binding engine. Essentially when you have something like a textbox you need to maintain synchronicity between the values displayed and whats stored in the db/file etc. The "old way" would be for you to write lots of repetative code for this yourself and deal with other factors such as what else might indirectly modify things. The new way all the code is written for you and you essentially just get a permanent logical data binding. The benefits are probably best articulated elsewhere but it does make for far faster, less error-prone, coding.

Beyond the above there is no specific requirement that I use it. Perhaps a MS Case Study would be nice. They did that with the first few games to be entirely C#.
Quote:Original post by ID Merlin
SQL has quite a few advantages for doing complex data retrieval operations [..]
SQL's advantages are its disadvantages at the same time. SQL is great if you need to be able to (re)formulate queries in a comprehensible way, and if you need complex things done. I love SQL from that point of view. It is a very sophisticated language to work with data in every imaginable way, and you don't need to care about anything (well, almost).
However, this comes at a high cost. Your SQL query is parsed, optimised, your input data is converted to a native format (after you converted it to a textual representation in the first place), and the result is converted to textual representation, only to be re-converted into native format by you again. You can work around some of this overhead by using stored queries et al., but the principle stays the same.
Using Berkeley, you can simply feed a struct into the database, and it will take it just as it is. Your abilitites to run complex queries are somewhat limited, but most of the time, you'll only want to execute something like "give me the data for player with ID no. 23423" anyway. In that case, you call a simple API function and get back a structure that you can use right away, without needing to parse or convert anything.

Sure enough, entire websites run content management systems written in PHP/MySQL, and they work reliably with little or no maintenance for years, so one could say "SQL is not that slow". However, if your web server is under some heavy load, creating a page can as well take 3-4 seconds (look at gamedev.net for an example). For a website, that might be a little annoying, but it does not really matter. For most games, 3-4 seconds are a killer.

Transactions are not a property of SQL. Although some SQL engines have transaction support, this is not what makes SQL (or, SQL does not make transactions).
For example, Berkeley has transactions, although it is not SQL.
MySQL has transactions since two years or so (might be incorrect, could actually be 3 years), but it did not have them for a almost a decade before, even though it is "SQL".

Quote:Does the Berkeley DB have a SQL engine or some equivalent available, also? If so, then that would be a great choice.
No, unless you count using MySQL with Berkeley backend. It's not what you would want to do, anyway. The reason why one uses Berkeley is because it is *not* SQL (i.e. it operates on native data and does not do any SQL parsing).
Quote:Original post by hplus0603
If you think your game can include MS SQL Server Express, then you can include that. However, I would recommend against it -- users don't like having arbitrary services (with known vulnerabilities) installed on their machines!



Default installs of SQL Server Express don't allow remote connections, only local ones. The only vulnerabilities to be exploited would by something already on the box.
Look at Firebird. It is free and open-source, but it has a commercial-friendly license. The project is a spin off of Borland's Interbase. It also can be deployed along side your EXE as a single DLL. From what I can gather it gives you a lot of the features of an enterprise level database (ACID, stored procedures, triggers, etc.) with the convenience of an embedded DLL. It seems like a good choice if you don't want to distribute and install a full database server, but want a little more standard SQL than SQLLite.
Don't tell him anything!

He's trying to hack the defence computers and let the cylons in.

This topic is closed to new replies.

Advertisement