How not to teach database design

It's awful.

It isn't that it's so bad if you just skim through it as somebody who already knows about databases, it's awful because it is trying to teach some basic concepts in database design and it does so very badly.

It isn't even just that the advice is bad in places. It also seems to have been written by somebody who has the empathy of a brick wall and the teaching ability of a dead albatross. At least those two working together mean that it probably won't have the opportunity to do much damage.

Here are five things to think about when writing a tutorial or exposition.

1. The introduction

A database is a collection of information related to a particular subject or purpose (e.g. tracking customer orders or maintaining a music collection). If your database isn't stored on a computer, or only parts of it are, you may be tracking information from a variety of sources that you have to coordinate and organize yourself.

There's nothing like the tired old cliché of starting off with a definition. The first sentence is probably only pointless, but the second… What does it even mean? What on earth did the author think we should take away from it?

Tip: See what happens when you cut the first paragraph from your article. It just might be better. And by all means write the introduction last, but don't keep pre-pending new introductions after every change like some wayward recursive function.

Not that the next paragraph is any better:

NOTE: Doesn’t matter how simple the system is, a flat-file database design (only one table) should not be employed, because it has severe limitations and inefficiencies. Your database should contain at least two tables and set relationship between them.

So, the author feels that they have to define what a database is for their audience, who will of course then understand this incorrect rant. The next time I only need one table in a database I shall be sure to split it to keep them happy.

Later of course we are treated to:

Database (sic) usually has more than one table, and these tend to be related in some manner.

Maybe the author forgot their most important note that a database must have more than one table?

2. Know when to stop

It actually gets a bit better after this. Cut the first two paragraphs out and the next part makes a reasonable introduction to what the author wants to discuss. Actually it's all the article should have been. Everything from “the basic steps in designing a database system” until just before “to determine the tables…” contains a succinct and poorly written primer to database design.

Tip: One page, one point; one article, one point. Stop when you've made it. We all know that there's a lot more tucked up in that head of yours trying to force its way out, but sometimes explaining less gives your audience a better understanding. They have time to think about what you are writing as they read it and you can take the time to make sure you are understood.

If you're writing a primer then keep it simple (stupid). By all means hint at greater complexity (in fact you should), but do it as an aside and don't introduce new terminology that not all of your audience will know.

If you're writing something for a more advanced audience then you will need to assume some prior knowledge. Only the very best writers and teachers have a hope of explaining advanced complexities to neophytes, and most of us neither write nor teach anywhere near well enough to try that.

3. Give examples and make them good ones

Four questions are posed for the budding database programmer to answer when choosing fields for a table:

Relate each field directly to the subject of the table.
Don't include derived or calculated data (data that is the result of an expression).
Include all the information you need.
Store information in its smallest logical parts (e.g. First Name and Last Name, rather than Name.)

I'm not sure that these would make my top four list, but apart from the last they're not the worst I've seen. Actually the first two are pretty good.

The last is questionable in the extreme though. It happens to be one of the only examples on the entire page, and it is wrong in most situations. How many applications really need to know anything about the structure of somebody's name? They're a lot less common than people think.

Tip: Use good examples. A good example is not obvious. A good example cannot be taken the wrong way. And most importantly, a good example illustrates in a way that a load of words (no matter how clever) cannot.

The point about using an example is to say something that the reader hasn't thought of and in showing it to them you make them realise the point you're making. At worst you're looking for that “ah hah!” moment. Ideally you want the example to lead the audience such that the point you are teaching is so obvious that they don't even realise they've learned it.

Separating first and last names does no such thing (certainly without the context of a concrete application). A better example is to separate the international dialing code from the regional code and the remainder of the telephone number because they are used in different contexts, but even this is long winded and awkward and not one I'd consider using (especially as the complexities of dealing with real databases means that you'd not make the separation no matter how logical it seems on paper — above all a good example is never controversial).

Good examples are rare because they are extremely hard to find. Maybe I'm not very imaginative, but I find that trying to get a good example often takes longer than writing everything else. I have entire articles finished but for the examples.

And my example would be? Well, that's kind of my point isn't it. When I do manage to think of some good examples I'll include them all in my own article on designing databases.

4. Keep your audience in mind

When linking tables you link the primary key field from one table to a field in the second table that has the same structure and data type. The link field in the second table is known as a foreign key field. By matching the values from the primary key to foreign key in both tables, you can relate two records.

Now I know what a foreign key is and I can't help thinking that this isn't quite it, even after I read it three times to try to work out what was being said.

Tip: You may find it easier to keep a real person in mind and imagine yourself to be explaining to them. In any case you need to have a clear understanding of your audience's understanding or you won't be able to teach them anything.

Writing an exposition is different to teaching when you are in front of the pupil. You must keep the pupil firmly in mind and think through from their point of view what questions are going to enter their head. This makes writing a good tutorial much harder than explaining something to somebody when you're in front of them as you have to be both teacher and pupil at the same time.

5. Be motivated

I can see how this article came about. Somebody over at databasedev.co.uk thought a primer on database design for people using Access would be a good idea. And who better to write it than somebody who makes these databases?

In its entirety the article lacks vision and clarity and I can't help but think this is due to the author not being particularly motivated to communicate — they're just writing a primer because the site needs a primer and not because they have any passion to teach database basics.

Tip: Write about what you know, and just as importantly write about what you want to communicate.

If you don't really care if anybody else understands database design or not you won't be able to teach them. No matter how many ticks you put against good teaching points it won't work because you don't really care if it does or not.

Even the most boring subjects can come to life and be taught by somebody who really wants the audience to know and understand and is able to think and write clearly.