While it may seem that I enjoy taking email industry people to task for posting bad, innacurate, and sometimes just plain wrong information, I really don’t….  Okay, maybe just a little, and maybe just sometimes.  I really do have better things to do with my time, but on the other hand, I think that it’s unfair to people learning the industry to fill their heads with misinformation. 

So what got me started this time? It was this little post entitled, “Relate to Customers With a Relational Database“.  What’s wrong with that post? I’m glad you asked….

Let’s start with what was correct about the post; relational databases and datamarts do exist. 

In the traditional sense, a “relation” is a single table; a row is referred to as a “tuple”; and a column an “attribute”.  In the purest sense of a relational database, a simple filtering of a field, or attribute, for a common value becomes relational to the value as the filter will show all records containing the requested value of the attribute.  In other words, if you filter a First Name field for all records containing the value “Bob”, the results are related to the value of “Bob”.

Therefore, in traditional terms, any relation (or table or “file”) that can filter data by attribute/field can be said to be “relational”.

If the author of the post had stopped there they would have been technicaly correct, albeit somewhat outside of the email industry lexicon.  But he didn’t because he goes on to compare a relational database to a “flat file” database.  As I just explained, a “flat file” can have relational aspects within the file.

To keep this relatively simple, let’s use some more common SQL definitions.  From this point forward we will refer to a “relation” as a table, an “attribute” as a column, and a “tuple” as a row. 

A relational data model consists of more than one flat file, where a Primary Key (not a “subscriber key”) associates row values between tables and may be queried across multiple tables to provide a single “view”.

In the example above, relational tables have been “flattened” to a single “view” (Results) of both relational tables.

Still with me? Good!

So now how does this apply to messaging?  Let’s use an example where the sending organization wants to assign subscribers to a unique sales person, and sign all messages to the recipient from the sales person.  We are going to use two relational tables; one for the subscriber information and the other for the sales rep information.

The table structure might look something like:

The populated data tables might look something like:

Notice that both tables contain a sales rep ID. 

In the subscriber table on the left, each subscriber is assigned a sales rep based on the rep’s ID number.  In the sales rep table on the right, the sales rep is identified by their own unique ID.  When we join the tables on the Primary Key (sales rep ID), the resulting view might look like:

One of the many things that makes this cool is that the two tables work independently of each other, and only come together when joined by the Primary Key. 

This means that if Chuck leaves the company and is replaced by Chet, the sending organization only needs to change Chuck’s information in the Sales Rep Table to Chet’s information.  The next time Bob receives an email it will come with Chet’s information as the sales rep.  If Denise doesn’t get along with Stephanie, the assigned sales rep ID for Denise can be updated to Steve’s rep ID and the next time Denise receives a message it will comes with Steve’s information. 

And it doesn’t end with just these two data tables. 

Let’s say now that we want to use customer purchase history to drive our message content.  We can add an additional “key” to connect the subscriber table to a purchase history table; or maybe an abandoned order table, or maybe an anything-you-want table. 

In this way data can become very modular, and with each table independent of the other tables, may be updated at different intervals for a variety of reasons.

A relational database won’t improve your relevance in and of itself; what it will do is help you to manage large amounts of data and for different messaging purposes.  Relational databases aren’t something that one should take lightly, and if it’s not something that you are familiar with, not something that you want to jump into without knowing all of the reasons for doing so. 

This just scratches the surface of relational database use in email messaging.  As you can see, leveraging relational data isn’t just skin-deep, and the applications are as diverse as the companies leveraging them.  In the end, if you’re going to take advice from someone about applying relational databases to your messaging, wouldn’t it be a good idea to work with someone that actually knows a little something about them?