Contextual review of your data

Ok Sam, we know from a broad prospective what information you want to gather about your customers. Now let's try and define a little bit more of just what these bits of data really mean.

You might want to know why we are doing this. Well, the main reason is that by defining more about just what the data is will help you to know if you are really gathering all of the information you want and that you are gathering the information in a way that can help you later.

Let’s look at each of the bits of information you want to gather and with each bit of information let’s talk a little bit about each. Included with each bit of info is a set of questions to help you define the information a little bit more:

Full name

We already said that you want to include the Mr., Ms, Mrs., etc in your data. Now, do you want to put this in with the full name or do you want to keep it separate? At the same time you said you wanted the full name are you looking at keeping that information together or are you going to separate the information into two bits of info? And how are you going to handle nicknames? One approach to this could be where you include all of the information in one field. In that case your data for this bit of information could look like [Mr. Timothy (Tim) Mayfield] (without the [ ] symbols.) This way you have all of the information together, and you have identified that he likes to be called Tim. Another approach could be where you divide the information into multiple bits so that you have one bit for Title [Mr. or Mrs., etc.], another for First Name [Timothy], another for Last Name [Mayfield], and another for Nickname [Tim]. This approach would be good if later you wanted to quickly sort by last name for example. Based on these two example approaches you can see that you are only going to be entering text data into this bit/these bits of data. How long you make each bit of data will be determined by the approach you take. If you use the multiple bits of information then each of them will have a different length, but you can guess as a standard rule that the bits could be 15 (first name), 30 (last name), 4 (title), and 12 (nickname) in length. If you use the combined approach then you would add all of them up and include 3 for the spaces between the bits.

Job Title

Well, for the most part this can be a simple fill-in text field. There doesn’t seem to be any reason to break this bit of information into multiple bits. As a standard rule this bit of information would normally be about 40 characters in length.

Company

There are two main approaches for this bit of information that you could use here: (1) maintain the information listing all of the companies your company works with in a separate data list and link that list to this as a selection option, or (2) leave this as a simple fill-in text field. Except for where noted in this lesson we are going with the assumption that you are going to use the simple fill-in text field for this bit of information. The reason is that later when we talk about different approaches that you can take some of them would give you the ability to leverage option one and others would never give you that cross-data relationship capability. Also, the rule for this bit of information is about 25 characters in length should hold this data.
You may be wondering why it would be worth the extra trouble to do something other than a simple fill-in text field. Well, that boils down to data integrity and when you start talking about huge database sets where there are hundreds of thousands to millions and hundreds of millions of records then you’ll see why you want to keep the integrity of your data.

Phone

With the phone for the most part we have a fill-in text field holding about 14 characters since the standard American phone number is formatted as: (123) 456-7890. Now, there can be discussions on only having the person enter the numbers and letting the data application (if you are using one) actually format the numbers to include the braces around the area-code and putting the middle dash in the main number set. Or you can leave it as an unformatted field. Since we are not looking into having this number actually acted upon by the computer (that is you won't be selecting it and having the computer dial the phone for you) then for this discussion we are not going to deal with specialized formatting or anything.

Address

When it comes to the address bit of data you have a similar discussion and decision path that we covered in the full name in that you could have all of the information stored in one block or you could break it down into multiple bits of data. For example, you could break the address bits into what is a more commonly seen approach: Address 1 [1 Main Street], Address 2 [Apt. 301], City [Sembach], State [TX], Zip [78125]. This way you could do more sorting or even some analysis on the data easier than if you put all of the data into one data set. The main key point here is "what are you going to do with the information right now and in the future?" If you think you'll never need to actually want to quickly, for example, list all of your customers who live in Virginia then putting all of the address in one data bit would be fine. By putting all of the information together does make it easier for you when you are going to be selecting your data storage approach because your data is less complex. But by using the less complex (all of the data in one bit) might hinder you if you later decide that you want that informaton broken out. To give yourself the maximum flexibility you should plan on requiring about 40 characters each for the Address 1, Address 2, and City. And two characters for State and 5 for Zip. If you are doing all of this in one data set then just add all of those numbers up and you would want to set aside about 127 characters of space.

Notes

In the Notes section you are going to be putting in information of a general nature that you and your co-workers might want to keep ongoing about your relationship with the customer. Really what you put in here would depend more on the services or support that you are providing to your customer and your business model rather than any specific data-centric definition of what goes into a notes section. The recommendation would be for you to allow as much space as possible based on your data storage approach. For now just consider this data set to be no less than 240 characters, and if possible based on the data storage method chosen this would be considered a memo field.

Now that we've talked about some of the context and structure you will be using when you are gathering and identifying the information you are going to be keeping on/about your customers we should move on to the problem constraints that need to be addressed.