How much information should the researcher keep about each site? Each interview? The answer, of course, is “all of it.” This can be an enormously time-consuming task, depending on the richness of the information the interviewer needs to collect about the site, the subject, and the interview instrument to be used.
Relational databases are purpose built for this sort of task. In a relational database, the user enters all the relevant information about each entity once, and only once. Whenever it is needed in the future, the database query looks up all the relevant bits of information from as many places as necessary for the task at hand. Many vendors are out there (Access, Filemaker, SAS, Oracle), but some of them are free and open source (MySQL, SugarCRM) and do not require years of study to become competent (OpenOffice).
To reiterate, you don’t need any money, and you don’t need a computer science degree to track your interviews in a relational database, but you can save yourself a ton of time.
Databases eliminate redundancy.
What does this mean, practically? It means you only enter the subject’s personally identifying information once, no matter how many times you interview the subject. It means you only enter the information about a site once, no matter how many time you use it. Once the information you need is in the database, you ask the computer to look up the relevant information whenever it’s needed: for monitoring progress, for publication, for output to a statistical program, for excerpting fields necessary for data coding, etc.
Eliminating redundancy means saving time. In a well designed database, you can use drop-down menus to specify sites and subjects for interviews once the fields for their identities have been created. Return trips to the same sites and subjects will be much simpler and faster.
Databases structure information.
Information contained in a database is structured. It is trivial to design a search for “all interviews that occurred at site XYZ,” or “all individuals belonging to group ABC,” or “all interviews whose subjects’ names begin with the letter N.” Once you’ve identified the records in question, the relational database will go look up any related information (e.g., about the site, or your local interview files) that are attached to the interview record you create.
That also means you can take advantage of context to improve your searching. For example, structured data enables you to find records with “pounds” only in the cost field and not the weight field, or “Washington” only in the street, or city, or state, or last name fields. To the extent that you want to analyze your data, structure is your friend.
Databases consolidate information.
Your records of interviews do not get split into separate word files, separate OneNote files, or separate Excel files. Instead, they are all managed in one central location, where each piece of information belongs to a particular category. These fields are meaningful because they can be searched.
Contacting individuals in your survey by email or snail mail is much easier with the database. Once you’ve entered the contact information into a single field, you can run mail merges based on the subset of individuals you wish to contact.
Subsequent coding of interview responses can refer directly to these locations, either in plain language, or with false names to protect the identities of the individuals, locations, and groups involved, again depending on how the report is structured.
Finally, you can attach the names and locations of files to your database. If you are managing a large load of transcripts or audio / video recordings of interviews, the database can track the location of these files.
Transcripts and recordings
Tracking audio and video recordings of files is even stronger in a program like iTunes. Major vendors are too numerous to list, but include Winamp, MediaMonkey, Amarok, Songbird, VLC, and Windows Media Player. Beyond permitting playback of the interviews, these programs enable the user to quickly append information to interview files through the use of tracks. Transcription software and services can now handle a variety of formats (e.g., MP3) that are popular with these programs.
Zotero also attaches local files (including *.doc, *.pdf, *.mp3, etc.) files to the bibliographic database. Interviews are identified by interviewee name, date, mode, and location; and custom fields can be added.
The essential principle of database design is to enter information with a simple, 1-to-1 relationship in a single table. For example, specify the uniquely identifying information for each individual in one table. For example, name and date of birth, often with contact information attached, form the unique information about an individual. Research sites should get a separate table: for example, the name and geographic location of the site, and any other information that is invariant with respect to the site. Participating organizations should be kept in a single table: location of incorporation, size, annual revenues, website, etc.
An interview should be designed using a query that pulls up relevant information from all three of these tables: the interview subject, the research site, and the participating organization. This is because a series of interviews may involve overlapping geographic sites, organizations, and individuals, with no strict hierarchy to the categories. For group interviews and web conferences, a single event may require multiple, related entries for each of those fields.
Database design is a whole field unto itself, which fills entire library shelves at most universities. Read some tutorials, get you elbows dirty, and don’t be afraid to make a few mistakes your first time out.