Performance analyzer: change data type to long integer (1 Viewer)

jeds

Registered User.
Local time
Today, 02:16
Joined
Nov 21, 2012
Messages
28
When I run the analyzer on all object types it recommends to change the data type for field "zip" (zip code) to "long integer to:

"benefit that table and potentially other objects in my database"

The field type is currently set to text, And I have the same setting for the same field in a separate table, yet it does not come up with a recommendation for that table.

Should I just ignore this?

Additionally, I don't seem to have the option "long integer" for the field data type???

jeds - using Access 2010
 

pbaldy

Wino Moderator
Staff member
Local time
Yesterday, 23:16
Joined
Aug 30, 2003
Messages
36,133
I would leave it as text, as long integer can't handle a leading zero which zip codes can have. It also can't handle the 9 digit code: 12345-6789.

FYI, the data type would be number and the field size long integer.
 

jdraw

Super Moderator
Staff member
Local time
Today, 02:16
Joined
Jan 23, 2006
Messages
15,394
I would further suggest that anytime you have numeric data, that you do not use with any arithmetic, just consider it a code and use text data type
 

jeds

Registered User.
Local time
Today, 02:16
Joined
Nov 21, 2012
Messages
28
I would further suggest that anytime you have numeric data, that you do not use with any arithmetic, just consider it a code and use text data type

So if you are not going to do any calculations with the data use text data type, correct?
Interesting.

jeds
 

jdraw

Super Moderator
Staff member
Local time
Today, 02:16
Joined
Jan 23, 2006
Messages
15,394
Correct. We used to call these sorts of fields "Identifers" or sometimes "codes" --- typically numeric values but no arithmetic - so data type was text

Things like
SerialNumber
PhoneNumber
StreetNumber
AccountNumber
 

Galaxiom

Super Moderator
Staff member
Local time
Today, 16:16
Joined
Jan 20, 2009
Messages
12,856
Some "general rules" about database design are really just personal preferences, often adopted without really thinking about it then promulgated as "convention". This thread is about one such rule.

Integers are considerably more efficient to store and index than text. I can see absolutely no reason to store a number as text simply because it isn't involved in calculations.

Where I work we have Member Number. No calculations done but I always use Long Integer. It is up to something around 150,000 after 45 years in business and Long Integer should see it through for another century or two even if we expand beyond anyone's wildest dream.

In Australia we have a four digit numeric postcode. It never has a leading zero and I store it an an integer. Why not?

Australian financial institutions have a BSB (Bank State Branch) which uniquely identifies it. It is consistently a six digit number but may have a leading zero. I store it as a Long Integer and use a Format string to display it with the optional leading zero and customary dash in the middle.

When it come to phone numbers the debate will really hot up.

Australian phone numbers can be split into the eight digit number (can be held as Long), area code and the country code. (In Australia the area code is a single digit dialled with a preceding zero to access an interstate or mobile call). Then another field can be provided for the extension. This is best as text because zero may be a significant digit in some extensions.

I work near a state boundary and I see it all the time. Some numbers entered with the area code and others without. It is inevitable where one control is provided to enter the phone number. Those who use a single field for phone have not completed a thorough data analysis. It is like using one field for Name.

The four separate controls clearly designate the entry requirement. I have only worked on databases in Australia but I have looked around and am yet come across a country where this kind of system wouldn't work.

I would be curious if anyone is aware of systems where this would fail such a local number which can have a leading zero and a variable number of digits.

Those who store phone numbers as text need to deal with the random insertion of spaces, dashes etc by various users. It gets really out of hand when they start storing extension numbers in the string too. "Ext-", "Ext:", "E", Everyone does it differently and it renders any attempt to automatically dial completely useless.

All non-numeric characters entered in an sub-number can be stripped in a numeric system whatever the user chooses to type. Storing as a number allows for a simple system display format to be implemented.

All comment and disagreement most welcome but those who have encountered me in debate before will know they had better have a well considered case.;)
 

Users who are viewing this thread

Top Bottom