Approach tables and joins

Here we focus on one of the most interesting and powerful concepts of relational database design; that of tables and joins.

What is a join and what is a table?

Recall that tables are collections of records that in turn contain fields of information. This is typically the type of information that should ideally be kept together. The simplest table I can think of is the staff list in an organisation. Together it keeps your staff's contact details in a single record in the form of a name ( a field) , telephone number (another field) , address ( another field), email account ( yet another field) and department (in which they work). The latter is also a field.

The information is not seperated, and each member of staff is allocated their own record.

Keeping it in one record makes it easy to find, this information is after all, all related, so why not store it in the same place? I might be labouring a point but databases are excellent at structuring information, and making it easy to find, which elevates them above any typical "spreadsheet" database. This leads us to the idea of joins.

Table Joins

Joins are connections between records on one table and a record in another.

For example The staff list table records the department in which each member of staff is employed. A list of departments are potentially a second table in our database. Creating this second table could enhance our staff list as we shall see. But why would we want to join or link two tables, the staff table and the department table?

Watch this space later this month for material covering this all important topic.