TS - Data entry policies - Kayako SupportSuite Help Desk Software

Support Center » Knowledgebase » TS - Data entry policies

	TS - Data entry policies

Article This section contains several pointer to the Best Practices involved when doing data entry to databases.

ZIPCODES.
In the US, the Postal Service has implemented a postal code in the following format: 99999-9999. Resist the temptation to use one field to contain the complete zipcode and divide it into the basic zipcode (with five characters) and the extended zipcode (with four characters). With these two fields, it is easier to find the CITY and STATE when the basic zipcode is provided. Else, you'll end with many "duplicate" fields like this:

LOS ANGELES, CA 90010-0001
LOS ANGELES, CA 90010-0002
...
LOS ANGELES, CA 90010-9999

Zipcode information should be stored in it's own table with the required fields, like: ZIPCODE CHAR(5), STATE_ABBV CHAR(2), and CITY CHAR(50), whereas extended zipcode should be stored in the table containing the location info for the physical address.

PHONE NUMBERS.
Just avoid using any non-number character and let the application format the data display. (213) 798-9995 contain extra character when compared with the raw number: 2137989995. Cardinality is always an issue with phone numbers, as a person can have several phone numbers and the same phone number can have several persons answering it. Don't attempt to create a field for home phone, office phone, cell phone, etc. Rather, use a LOCATION table to relate a PERSON with a PHONE, like this:

PERSON TABLE LOCATION TABLE PHONE TABLE
----------------- --------------------- ----------------
JOHN DOE OFFICE 2137899995
JOHN DOE CELLPHONE 7141234567
...

This way, people who have several phones will have likewise entries, but those who have less phone numbers to be located, won't have empty entries.

Article Details

Article ID:

Created On:

19 May 2010 6:24 PM