Database Reference
In-Depth Information
typical multiple-choice test. This test was delivered on paper and graded
by hand. This was time consuming, and it wasn't much fun. Because I was
a budding technology geek, I wanted a better way.
Enter my Visual Basic testing application, complete with the Access
back end, which in my mind would look similar to the Microsoft tests I my-
self had recently been taking. All the questions would be either multiple-
choice or true-false. At this point, I hadn't done much with Access—or any
database application for that matter—so I just started doing what seemed
to work. I had a table that held student records, which was straightforward,
and a table that held information about the exams. These two tables were
just about perfect; they had a purpose, and all the information they con-
tained pertained to the entity the table represented. These two tables were
also the only two tables in the database that were easy to navigate and re-
trieve data from.
That brings me to the Question table, which, as the name suggests, stored
the questions for the exams. This table also stored the possible answers the
students could choose. As you can see in Figure 1.5, this table had problems.
F IGURE 1.5
An example of a poorly designed Question table for a testing
application
 
Search WWH ::




Custom Search