I think you are confusing a “field” with a “record”.
Fields are small pieces of data assiciated with each other that need to remain linked together to make sense. For an application like yours, typical fields would be: first name, last name, address line 1, address line two, city, state, zip, phone number, and mabye a couple of extra things like a salutation (Mr. Mrs., Ms.). Your method does in fact accomplish that, and so I can’t say it is “wrong”. But it severely limits how you can use the information.
Ideally the data for each field is stored in separate and adjacent cells – I’ll get to why later. All the information in those fields about a single person constitute constitue a single RECORD, and each record is fully contained in a single ROW. Each field “type”, ie, address or zip, is contained down a single column, as Jpeg Jone’s example of a data structure.
Before I go any farther. let me say that if your rolodex list is only 10 or twenty names (what you can more or less see on a single screen), and you ONLY want to be able to glance at it to look up a name or address, that I’d say what you’re doing is okay.
But if you want to be able to do any more than one of these other things, then it will be well worth your while to restructure your data as Jpeg suggests:
- print the names and address on envelops
- print the names and addresses on mailing labels
- Write a single letter, which you want to duplicate and send out individually addressed to everybody on the list. (Or everybody on the list from California, or from with a certain range of zip codes, or everybody with the first name "john, etc)
- Sort the list by any field. (Maybe you remember one contact’s name as John, and another as Mr. Smith – you can sort so all Johs, or Smiths, or Misters for that matter are grouped together for easier finding. With your design, you can search for each John one at a time, and spend a lot more time and keystrokes doing it).
- Automatically count how many of your clients are in each city, state, or whatever.
- Delete duplicate rows of data
- Many many more things that I haven’t thought of…
Technically* Access * is an even better program for these functions, but it is not very intuitive, and the report functions which determin how the data prints out onto a page are pretty cumbersome. I would agree with others who say that you can stick with Excel for the job.
And the biggest risk in using Excel for this kind of data is something that your system, as limited as it is, DOES prevent. The risk is that you can sort one or more columns of this data, and NOT sort the others, which essentially breaks up record into peices that you won’t be able to reassemble without a great deal of trouble. (Access prevents this, which is why it is a theoretically better tool).