What Is a Database?

A database is simply an organized collection of information. It allows many different types of data to be stored and retrieved in a highly efficient manner. Information within a database is organized into tables. A table is simply a collection of fields, which can each have their own unique data type. For example, you could have a single table in your database that contains a player's name, age, and e-mail address. Once you have tables defined in your database, you can then add records into the tables. A record is a single entry in a table that contains data for each of the fields specified in the table.

Figure 14-1: A visual interpretation of a database

There are many different types of databases, but the one we are most interested in is the relational database. A relational database is a database that contains tables of information that relate to each other in some way or another, and the information in the tables can be accessed and organized in many ways. This is usually accomplished by means of unique identification numbers, although this identification can be done with any data type, but the most effective way is to do it with number types. Therefore, each record that is added to a table in a relational database will be automatically assigned a unique number if the field is numeric and if a sequence and a trigger is defined to the table to do that. There are database packages that can do this almost automatically by defining that the field is an identity field. This unique field will differentiate it from all other entries in the same table (but not entries in other tables). This allows us to optimize the data within the database as we can simply make a field in a table an integer (or any data type—actually, sometimes there are situations where varchar (string) fields are better reference fields than integer).

A good example of where a relational database could be used is in a simple chat applet. The user's information could be stored in a table called userinfo, which would contain the login name, password, and e-mail address. Also, each record (of user information) would be assigned a unique identification number automatically by the database, so there would always be one field in the userinfo table (the unique number field) that could identify a single record from all the rest. Now our database would contain a single table that held user information. What would we do, though, if we wanted users to have a contacts list into which they could add their associates to the chat system? We could have a separate table that would be named using the user's login name (for example, if the user was called "bobby," the table would be named "bobby_contacts") for each user. Each of these tables for the users would contain duplicate records of their contacts' information for all the users that they have added to their contacts list. Here is how our tables would look in the database if Bobby had added two other users called "Sandra" and "Jenny" to his contact list.

Figure 14-2: Visualization of an inefficient method for storing user contact information

As you can see, this would be a very inefficient method of storing the contact information, as the same information would be replicated many times and the database could have hundreds of tables in it (i.e., one for each user), which would be inefficient from a data access and storage point of view.

The ideal way to deal with this problem would be to use the features of the relational database. That is, use the unique number field that has been assigned to each user automatically by the database. Instead of creating an individual table for each user, all we need to do is create a single table for use by all the users, which "pairs" up users with other users that have been added to their contact list. We will call this new table relate_contacts_to_users. This kind of table is often referred to as a link table. The table will contain two integer fields to store two users' unique numbers and also its own uniquely assigned number to conform to being a relational database. So when a user adds a friend to his or her contact list, the applet will add an entry into this new table by adding the user's unique number into the first field and then the friend's unique number in the second field. This constitutes a complete record in the new table. Therefore, we can add many friends to a single user with the expense of only three integer values, rather than duplicating the many strings and integers that represent users' details. Here is how our database would look if Bobby had added Sandra and Jenny as contacts using this more efficient method:

Figure 14-3: Visualization of an efficient method for storing user contact information

Therefore, using this better method, if we then wished to add Bobby and John as contacts for Jenny, all we would need to do is add two extra records into the relate_contacts_to_users table to relate the unique ID numbers of Bobby and John to Jenny's unique ID. Here is how our relate_contacts_to_users table would look after we add this information into it:

Figure 14-4: How the relate_contacts_to_user table looks after the addition of Jenny's contacts

This technique has many applications when it comes to storing data in an optimal way and can also lead to accessing data faster. Also, it removes the limitation of predefined fields, as players can have as many friends as they want due to each new friend simply being added as a record to the relational table.

Now that we have the basic idea of what a database is in our minds, let's look at why we would use one in the creation of a game in Java.