You won't get very far while building ColdFusion applications without the need for a relational database. Since ColdFusion is so easy to use, many developers come from non-programming based backgrounds, and proper database design remains a mystery.

Perhaps you've worked on other applications, such as a spreadsheet application in Microsoft Excel or used an Access database with a single table to store data. Both of these options serve their purpose, however they are not the best choice for web applications. In this architecture focus issue, I wanted to take some time to introduce you to relational database concepts.

Understanding the Terms
Before I start blabbing about database this and database that, I want to make sure you understand what I'm saying. So let's start by defining some common terms that you should be familiar with.

• Database: A database is any collection of related data. It could be as simple as a grocery list or as complex as a full Enterprise Resource Planning application. The database is made up of many elements, starting with...
• Tables: A table is similar to a single spreadsheet. A relational database is made of multiple tables. Tables are made up of columns and rows. A column represents a single piece of data, such as a name, zip code, or street address. A row represents a single set of all columns. No two rows within a table can be identical. You can relate tables together using ...
• Keys: There are two types of keys in a relational database. A primary key is a column, or group of columns, that can uniquely identify a single row in the table. A foreign key is a column in one table that can be used to uniquely identify the row from another table. It is through the use of primary and foreign keys that you define relations between tables.

Database Normalization
Normal forms are a way to check that your database structure is correct. There are seven different levels of normal forms and each normal form exists to avoid a certain anomalies, that will not allow you to insert, or delete, data without also inserting or deleting a piece of unrelated data. You probably don't need to know specifics about the each level of normal forms. When developing a database, you just want to think about storing each piece of data only one time. You don't want duplicates. In your table structure, have you duplicated data somewhere? If so, you may want to re-work your structure so that you don't.

This will probably make more sense with an example. Suppose you were writing a program to catalog your CDs. You might start with a list of sample data, maybe something like Table 1. This is a table with four columns: Artist, Album Name, Genre, and AlbumID. The AlbumID is intended to be the primary key of this table. In a real application, you'll probably have a lot more data, such as a song list for each album, release dates, or the names of band members. We'll keep it simple for this example, though. If you examine the data, you'll notice some places where the data is duplicated. The artist name, Guster appears twice. The genres Grunge, and Alternative appear twice. If you were building an on-line record store, you would not want to store the genre or artist name a lot of times.

This table also exhibits insertion and deletion anomalies, which were discussed earlier. What happens if you want to delete the Bishop Allen album? You will also inadvertently delete the "Rock" genre. That is a deletion anomaly. What if you wanted to create a genre for blues? You wouldn't be able to do so without also entering an album. That is an insertion anomaly. You want to build your tables to avoid these sorts of issues. So, how do you do it?

Well, in this situation, you may first want to separate the Genre into its own table. You can see the genre table in Table 2. I added a GenreID column to the table. This is an integer column intended to be the primary key of the table. We can also split out the artist information into a separate table, as shown in Table 3. The table has two columns, a primary key named ArtistID and an artist column. With the artist and genre information moved into their own tables, what does your original album table look like? There isn't much left, just a primary key and an album name. However, you'll still want to preserve the relationships between the album, genre, and artist tables. How do you do this? You take the primary key of the genre and artist tables and put then in the album table. Our updated album table is shown in Table 4.

Why is this different? Well, it takes less disk space to store an integer than it does text. While you probably won't notice any problems in tables with just a few rows, the difference becomes much greater when you are dealing with larger amounts of data, such as a song database with a thousand records, such as iTunes. Each little bit starts to add up.

Database Relationships
There are really three different types of relationships that come into play when putting your data into tables. The first type is called a one-to-one relationship. This means that for any single piece of data A, there will only be a single piece of data B. If A, were a username, then B might be a password. For every username, there must be only one password and for every password there must be only one username. In most one to one relationships the data is stored in the same table. If for some reason you are splitting the data between two tables, you can represent the relationship by moving the primary key from either table into the other table as a foreign key.

The next type of relationship is a one-to-many relationship. This means for every piece of data A, there will be multiple pieces of data B. For every piece of data B, there will only be one piece of a data A. A good example of this is the artist/album, which we described above. For every artist, there may be multiple albums. But, each album only has a single artist. (For the sake of this example we are ignoring multi band compilations). You can represent one-to-many relationships by taking the primary key of the "one" side and put it into the table of the "many" side as a foreign key. This is what we did to split up the album and artist tables. Our example, above, created the genres and albums relationship as one-to-many.

The third type of relationship is a many-to-many relationship. This means that for every piece of A data there will be multiple pieces of B data, and for every piece of B data there will be multiple pieces of A data. Perhaps, you've got the Aerosmith album. It's rock. It's blues. Where do you categorize it? The Genre relationship to an album could be a many-to-many relationship. To implement this type of relationship in the database, we create a special type of table, often called an intersection or linking table. This table does not usually contain any data, only the primary keys of the two tables that it is linking. To implement a many-to-many relationship between genres and albums, we would use the GenreID from the albums table and create a new table, as shown in Table 5.

I know it looks like a table of numbers, and that's what it is. The primary key of intersection tables is usually made up of all the columns in it.

Common Database Design Mistakes
Before wrapping up this column, I want to finish off by pointing out some mistakes I often see beginner developers making. All of these are obvious in hindsight, but you probably don't realize you did it "wrong" until you have a problem and the light bulb inside in your head brightens up, and "Uh-oh" escape from your lips.

• Names: You have a site registration, or an address book application, or something that requires you to collect and store the names of your users. Make sure that you store the first name and last name as separate columns in a database table, do not combine them. If the data is being collected, at some point you are going to be asked to do a mail merge. When you do that, it'll be a lot easier to do if you have the first and last names separate, so you can address people as "Mr Houser" instead of "Mr Jeff Houser."
• Deleting Data: It's easy to write a delete statement in SQL, but what happens when your client or boss calls up to ask where their data went? If the data is truly deleted, you have no way to restore it. If you're lucky you have backup tapes, from which you can restore yesterday's data, but that can get messy. A better way is to not ever allow users to directly delete data. Create a Boolean field in your database table called Deleted. If set to 1, the record is flagged for deletion. If set to zero, the record is fine. You can run batch scripts on a routine basis to delete the data, as needed. When the user calls up to find out where their data is located, you can just flip that flag to restore it for them.
• Store the Date: At some point, someone is going to want to look at the data you've been collecting through the web site. When are people registering on the site? When was the last time they modified their information? On most tables, I will add a "DateCreated" field to store the time that the record in the database was created, and a "DateLastModified" field to store the time the data was last modified. On some projects, I've had a few "higher ups" quite shocked that this data was not being collected.
• Define Relationships: You should always make sure you use the built-in facilities of your database to specify keys, and define relationships between tables. In addition to helping you protect your data from inadvertent corruption, the database engine can often use these relationships and keys to automatically optimize queries. I've had quite a few sleepless nights trying to fix the invalid data that had resulted from deleting one piece of data, without deleting data that relates to it. For example, what if we deleted a genre, but did not delete the entries in our intersection table that related to that genre? Something is going to break somewhere.

What Next?
The relational database is the center of most advanced applications, web-based or otherwise. Some of the more common databases used in ColdFusion development are SQL Server, MySQL, and PostgreSQL. Oracle often shows up on sites with larger load, and Access will sometimes show up on smaller sites. I would recommend putting aside some time to learn about the database of your choice, because many of the skills you learn can easily be transferred to all database platforms.

• Microservices and Legacy Apps | @DevOpsSummit #DevOps #Microservices

• Table 1
• Table 2
• Table 3
• Table 4
• Table 5