A Database Table

Most often, we query information from a database where that information is stored inside a table structure. Most explain a table as a series of rows and columns. Much like a spreadsheet where the spreadsheet is the TABLE, each line (horizontally across the page) in the spreadsheet is considered a ROW, and then sets of lines (vertically down the page) are denoted as a COLUMN. Each cell (the intersection of a ROW and COLUMN) is then considered a VALUE of a COLUMN for a specific ROW. For example, look at Table 1. The table is called DOG_ORIGIN, and represents the country a particular bread of dog originates. There is also a designator for the size of the bread. We will, at a latter date, discuss the types of VALUEs (or data) that can be stored in each column. For now you can see there is just TEXT data; the COLUMNS are COUNTRY, BREED, and SIZE. A ROW is composed of an occurrence of COUNTRY, BREED, and SIZE.

We are not going into table design concepts or modeling here. However, please note that there are repeated VALUES in the COUNTRY and SIZE COLUMNS. Also, note that there is no pre-defined order of the rows in the table. This is a key concept when writing SQL and is often times misunderstood. Just because rows of information were created in a table, in a particular order, does not mean they will be returned in that order when extracted with a SQL statement.

Table 1.
DOG_ORIGIN table

Often times a TABLE is defined textually by the following notation.

DOG_ORIGIN(COUNTRY, BREED, SIZE)

There is nothing you can do with this notation but makes it easy to read and communicate the columns of a table.

Often times the individual COLUMNs of the TABLE are denoted by a dot. This ‘dot’ notation containing table_name.column_name is used quite often in SQL and you should get familiar to this representation. There is an example later in this article.

DOG_ORIGIN.COUNTRY
DOG_ORIGIN.BREED
DOG_ORIGIN.SIZE

Writing a simple SQL Query

The SELECT statement is the basic unit for extracting information from a database table. While there are many options within the SELECT syntax, there are only four required parts to form a valid SQL SELECT statement. Table 2 contains the required parts of a SELECT statement. These definitions are in their simplest form; I will expand on them later in this article.

Table 2.
Required parts for a SELECT statement

Therefore, if we wanted to list all the COUNTRY of origin and the BREED of the dog from the DOG_ORIGIN table we would construct a SELECT statement as follows.

SELECT country, breed FROM dog_origin;

The query could also be written in two different forms. The first uses the TABLE name as a prefix on the COLUMNs that are being selected. The second uses an alias for the same purpose as the first option. Alias can be any character string. Some people use letters of the alphabet (a,b,c,...) while others use some abbreviation of the table name. It does not matter what you use. Just try to make it consistent throughout your code so that you do not confuse someone. The reason for using the table name or alias is for more advanced queries where a query might be selecting from two different tables that have a column name that is the same. The alias specifies to the database engine which table you would like the column to be queried from. This will become clearer in Part III of this series.

In addition, this is a good place to introduce the concept of the wildcard ‘*’ (an asterisk). The asterisk can be used instead of listing the individual COLUMNs of the table you are selecting from. For instance, consider the following.

SELECT * FROM dog_origin;

The database engine at this point will expand the asterisk to mean all of the columns in the dog_origin table. While this might be a very handy and quick way to get everything, it is a very discouraged practice. For many reasons I will not go into, the asterisk basically is inflexible when trying to use it within a true database application and typically causes applications to break when the table structure changes by adding or removing columns. So it is always a good practice to list each and every column you really want to be used in the query.

If this all is second nature to you, GREAT! Please be patient as there are many without this basic understanding of SQL queries and we all need to start somewhere. If this is still confusing to you then please send me an email. SQL is one of those lost arts. We often just throw something together without considering the ramifications to our applications and the database engine that must crunch through the tables to get at the information we require. Bear with me. This series will introduce more difficult SQL as time goes on. Just read each and every part, try the SQL and let's become the next SQL experts.

Previous   Next

Back to DBAsupport.com