Considering something like Contact Info I'd do something like below. I'm not including every possible attribute, just trying to give some ideas. I can't tell you how many wasted and expensive hours I've spent on parsing names and addresses just to mention two categories of contact info. Generally speaking I'm inclined toward more granularity when designing a database structure. Those who just dabble with writing simple queries seem to prefer the spreadsheet model you've described because they don't have to worry about doing complex joins, where clauses, grouping, etc. I've been told before to "just put it all into one table" and of course before the project goes live the same person who insisted no one--no one!--cares about fax numbers anymore makes a last-minute request to add fax numbers.
I'll say again: this is a very simplified model. What actually needs to go in the various tables is always based on the needs of the application.
ContactID --(could by a natural key like CustomerNumber or SSN)
Prefix -- the following 5 categories are a minimum when entering names
MaidenName --or any other UNIQUE traits like:
--What needs to be in an address table varies country to country.
--In the USA it's best to get the USPS address guide and enter
--addresses in the proper format to start with.
Table:Address -- allows any number of addresses per contact
AddressDesc --optional descriptive name such as "My Office" or "Spouse's Mom"
AddressPrefix --S, East, NW, etc
--Just like addresses
--Best to present the end-user a list to choose from or you wind up with a million variations.
--All of these tables allow for adding a new 'type' at any time or changing the description of a 'type'
AddressType -- shipping, mailing, home, office, vacation house, etc
AddressTypeDesc --optional for allowing longer descriptions
--Could be Customer, Agent, Relative, etc
PhoneType --home, cell, office, fax, etc
--I like to use a cross-reference table because you can sometimes have more than 1 contact at the same address
--as well as multiple addresses per contact
--For the same reason as addresses
--It's possible to have other attributes for a contact that are one-to-many;
--sometimes an EAV model is used in such a case but that opens up Pandora's Box
ChildFirstName (Middle. Last, etc)
ContactPurpose --which would relate to a ContactPurpose table
EmployeeID --which might relate to another set of tables for sales people, support, canvassers, etc
--These last 3 tables or tables like them could be done using an EAV model;
--this would allow limitless contact profile categories but can be a beast
--when trying to write efficient queries. Very flexible though if the category
--types and hierarchy cannot be easily predicted.
DefinitionParentID --so a hierarchy could be built
DefinitionLevel --again for hierarchical use
DefinitionType --Children, Associations, History, etc.