Relational Databases Make It Easier
The purpose of having a database is to make it easy to handle your data. The way you store and structure your data plays an important part in how easy and simple it will be to work with.
Imagine you have a list of customers and prospects. As a minimum, you would probably have the following information about each company:
- Company name
- Phone number
- Names of important contacts
- Contact emails
- Contact mobile numbers
If you had this data stored in a spreadsheet, or on paper, you would have to have a separate line for each person (contact), because they each have a different name, email and mobile number. But that also means that you have to repeat all the company information (address, phone, website, etc) for each contact in the same company.
In a “relational database” you would store the company information in one place and the contact information in another place. In database terminology, these different “places” are called “tables”.
So, you have a table for company information: name, address, phone, website, etc. In this table you only have to enter and store the ABC company data once, not three times, as above (or a hundred times, if there are 100 contacts in that company).
Then you have another table that contains only contact information: name, email, mobile, etc. All you need to tie them together is a linking ID number that represents the company that the contacts belong to. If you allocate a link number (say 101) to the ABC Company, then all you need to do is add that same link number to each of the three contacts who work at the ABC Company. In other words, you are setting up a “relationship” between the contacts and the company they work for. It would look something like this:
Let’s take this further. Look again at you spreadsheet, or the list of your companies and contacts on paper. Now, suppose you want to record some information about particular contacts. Not just one-time information, but repeated information, like notes of the calls you make to that person. You might make 20 phone calls over a period of months. It would be really valuable to be able to look back at the details of previous conversations.
To do that, you would have to have other pieces of paper to record those note on, or you would have to draw you list up on a much larger sheet of paper. On a spreadsheet, you would need to add extra rows to each contact for the added notes.
Take this further – suppose you want to record which seminars that contact has attended, or what meetings you have had with them. Once again, these are repeated activities about the one contact that need to be recorded. Your spreadsheet or paper file is starting to get very complicated. Pretty soon it will be unmanageable. It’s supposed to be easy, right?
With a relational database, all this becomes very easy to manage.
- You want to add notes to particular contacts? Just add a Notes Table linked to the contact; one contact with many notes.
- You want to record all the meetings you have with a particular contact? Just add a Meetings Table linked to the contact; one contact with many meetings.
You get the idea. The spreadsheet or paper method is a start point to data management, but it is severely limited. Moving to a relational database opens up a wide vista of possibilities.
You will normally need some assistance in setting up the structure and operation of a relational database. Once set up, however, you will have a system that is a thousand times easier than your spreadsheet/paper solution.