Database Creation & Management for Meeting Planners

A Philosophical Approach to the Basics

How many of you reading this use at least one database in your work? Most of you should be raising your hand right about now as databases are an inseparable part of meeting planning. If you don’t believe me, I have just one word for you: Registration. For you suppliers, thinking this doesn’t apply to you… think again. You, too, use databases on a regular basis – just check out your contact lists or the programs you use to check what space is available when planners send you an RFP. All of these are databases and, if you use an off-the-shelf program like Microsoft Access or FileMaker Pro, there are a few strategies and techniques to bear in mind to make the final “product” user-friendly and effective. In this column, we’ll take a quick look at some of the basic concepts of database Functionality, Structure, and Appearance.

Functionality Step One: Put Down the Mouse! That’s right – put it down! Most people want to start right away and get to work, making it look good right off the bat. However, before you begin typing, you need to do some thinking. Functionality is the first thing to address. It is primarily about purpose, but does need to take into account who will be using it – so your two basic questions at this point are: what do you need it to do and what is the user’s skill level/comfort level with the software? Each of these questions can lead to very different databases depending on the answers you come up with. A registration database that has to be regularly updated to track payments, purchase orders, menu and workshop selections will be quite different from a database set up to track your CD collection. Similarly, a database that my great aunt Helen would be comfortable using would look very different from one set up for my brother, the computer programmer. Just remember that the only “right” answers to these questions are honest answers.

Once you have decided what the database needs to do for you and who will be using it, you can begin to build the Structure that will support the final product. Again, spend some time thinking about this before you begin actually working on the computer with the software. The single most important item that exists in any database, regardless of the software, is “the field”. Fields are where your data will actually go once you start using the database. How they are set up and how they are named (yes – named!) can make or break the file for you. Typically, you can set up fields to contain text, dates, numbers, or even pictures. If you are not sure what you need a field to be when you begin, it is usually best to leave it as text, which is generally the default type. The software program you are using will dictate what you can set up fields to be and how that needs to happen. Of more importance, though, is the naming of the fields. My two rules for naming fields are: 1) Make it Short, and 2) Make it Obvious. If I use the field names FN, LN, O, and A, I have definitely made them short. Are they obvious, though? You might recognize them as First Name, Last Name, Organization, and Address – or is it First Notice, Last Notice, Order and Agency…? You may not think this is a big deal, but consider what might happen if you have a large database and many people entering data. Even if you are the only person who will be using the database, you may forget after a month what the field names meant. [Note: my usual field names for these four are FName, LName, Org, and Address.] If you make the field names too long, it may distort how you view or print records from your database.

Now that you have created your fields, you can begin making the database “look pretty” and work on its Appearance. The key thing to keep in mind here is: how does it “flow”. In other words, is there a logical progression in how you maneuver through the database, or does hitting the tab key just cause the cursor to jump around the screen. I like to group data together into coordinated blocks of information on the screen. I’ll put all of an attendee’s contact information in one spot, their payment information grouped together in another, and correspondence tracking in yet another grouping. This allows me to look at an attendee’s record and quickly find the information I am looking for. I also make sure that fields are placed in an order that makes sense to me (and, hopefully, other users). The field that is for someone’s last name follows the field that contains their first name, and so forth. If the database flows well and makes sense to you and others, it will be much easier to navigate through and makes finding specific information a snap.

Fancy extras like scripts, buttons, calculations, and alerts are wonderful tools that can certainly make things easier for the average user but they do require a bit more knowledge and understanding of the software to use properly. If you remember some of the basics, you will be in good shape no matter what software you are using. Even if you are not the one creating the database, knowing what it was built to do and who was intended to use it is helpful – especially since not all database designers talk to the people who will actually be using the file! Knowing the structure will help you to make changes later (or suggest them to the designer). Keeping field names short and obvious means that anyone (including yourself) can understand what you have created. Having notes actually included in the database is also a good way to remind yourself of what you did in certain places. Finally, making sure that the database “flows” well will make even the most complicated file easy to manage.

Function, Structure, and Appearance form the basis of every database. What we’ve gone over here is just the tip of the iceberg and, if you are interested in learning more, there is a wealth of information out there about every database program on the market. If you work with a custom database, designed just for your company, talk to the designers if possible and get your information from the source! Remember – no single program can be everything to everyone. This is why most database programs are customizable by the user (that’s you!) and partially why there are so many options to choose from. If you are in the market for a new database program, take the time to learn about what the software can do – don’t just grab the first box you see that has a cool cover! Decide what you need it for, who will be using it, and how flexible it will be to your changing needs. If you already have database software, which most of us do, then you are ready to jump in and start building the database. Just remember to keep Function, Structure, and Appearance in mind as you do so…

Karl Baur, CMP • Project Director, RDL enterprises

This piece previously appeared in the September/October 2007 issue of the Pony Express, the newsletter of the Sacramento chapter of SGMP, and is used with permission of the author. – ed.