Page 1 of 1

game databases???

Posted: Thu Nov 23, 2006 9:53 am
by Kaila
I'm rather new at this MySQL stuff.. but what I am doing is making an online game.

I have a "management" database, that I really only want to use for the users. In that db, I have four tables. They are users, active_users, active_guests, and banned_users.

In the users table, it logs all of the registration information, such as username, email address, and the sort. In my current login system, I do not have a static id for each user. One of my questions is, will this pose a problem in the long run? The login system I used is the one at Evolt.org with the admin features and such.

In this game, I need to store in a database the horses and other animals, buildings, etc. owned by this user. Is there anyway possible that I can create, say, another database named animals, and in that db include tables for horses, cattle, dogs, and cats? I was thinking that you would have to do this by including one of the same fields in both db's/table(s) such as username, and link them in some way using PHP.

I'm not sure, but my reasoning behind this is that a mysql table can get overloaded and become slow or run out of space? I want to prevent this from happening, if it's even possible. Not to mention this way would keep things alot neater for me and the rest of the staff.

I know this will take alot of work, and it needs alot of complicated PHP, and all that stuff. Let me at least try though.

Thanks =)
Kaila

Posted: Thu Nov 23, 2006 10:04 am
by feyd
MySQL, as with many other databases, is engineered to handle VERY large tables. Hundreds upon hundreds of millions of records with little problem. I don't see a need for separate databases for your property tables.

Typically the tables will be decomposed such that duplicated fields that belong to all property are in one table and specific sets for specifics of the various types are added to a separate supporting table. Sometimes it's not best to do this, but often it is. This concept is referred to normalization most often.

Thanks

Posted: Thu Nov 23, 2006 7:45 pm
by Kaila
feyd wrote:MySQL, as with many other databases, is engineered to handle VERY large tables. Hundreds upon hundreds of millions of records with little problem. I don't see a need for separate databases for your property tables.

Typically the tables will be decomposed such that duplicated fields that belong to all property are in one table and specific sets for specifics of the various types are added to a separate supporting table. Sometimes it's not best to do this, but often it is. This concept is referred to normalization most often.
For the first part, thank you for clearing this up for me. I wasn't exactly sure how I should set up the database(s). But, in the second part, could you please clarify the concept of normalization, or reffer me to a tutorial or something that can? I don't mean to sound like a blonde here, but I sort of am. =P

Posted: Thu Nov 23, 2006 8:30 pm
by feyd
Searching here could lead to useful information, http://www.oreilly.com/catalog/javadtab ... r/ch02.pdf could be a starting point too. Wikipedia has some articles on normalization too.

Google should be able to find a lot of resources.