• Post Reply Bookmark Topic Watch Topic
  • New Topic

Anyway to store Integers or ints with leading zeroes without resorting to Strings?  RSS feed

 
Eric Matthew
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm making a program that is storing over 40,000 different zip codes and many of these zip codes have leading zeroes. I know I can use String to get around that but I learned that it's best to avoid using Strings for numerical types of data so I'm trying to avoid that route. Or is it best for this particular case to use Strings as opposed to the numerical types? Plus, I just read "Strings are bad" http://www.coderanch.com/how-to/java/StringsAreBad so that's why I'm mainly avoiding wanting to use Strings as well.

Oh, just to clarify. I understand that 00555 is the same as 555 and such.

Additional info if it helps: The zip codes are stored in txt file that are read from a scanner object.

Here's the code FWIW



And oh, I know I can make my code a bit more clearer by removing unneeded variables but I left everything in place til I can get some guidance how to proceed.
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

On one hand, an integer variable does not have a concept of format -- so, if you want leading zeros, you can't use an integer (as there is no way to store the number of leading zeros).

On the other hand, zip codes have a known size, so you don't need to store the number of leading zeros. You can use an integer to hold the value, but when it is time to use the value (where leading zeros are needed), you can format it to a string then.

Henry
 
Eric Matthew
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the response Henry, I thought about going through that route - just storing them as Integers/ints than when the values (for the Integers) are called, then checking to see if the value is greater than or less the known boundaries for zip codes. Seems a lot better than storing a bunch numerical types as Strings.
 
Campbell Ritchie
Marshal
Posts: 56529
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, you should not store them as Strings; store them as ZipCode objects. Create a class which stores the number and whose toString method returns it with leading 0s added. Henry has already given you hints about how to store the data, but with encapsulation that becomes an implementation detail which users are kept unaware of.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66304
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never store zip codes as ints. I have the scars to show for some deluded database designer who thought that storing zip codes as ints was a good idea. Despite the fact that they are composed of digits (at least in the US, and only if not using the 9-digit format), they are conceptually strings, not numeric values.

Avoid the pain and the scars and don't even think of them as numeric.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66304
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:No, you should not store them as Strings; store them as ZipCode objects.

I know of no databases with a ZipCode type. Strings are the way to go.

Perhaps in a memory-only scenario (which I have never encountered), or a scenario where they must have complex manipulation, creating a model object for a zip code might make sense, but for simply storing them in a database in order to display them on-screen, I don't see the need for anything more complex than a string.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66304
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And with regard to "Strings are bad", be wary of taking a knee-jerk approach to applying such admonitions everywhere. Think of it as "Strings are bad when using them for things that aren't strings"

Sort of like tables in HTML; they are only "bad" and when used inappropriately. They are fine to use, and should be used, for tabular data.
 
Piet Souris
Master Rancher
Posts: 2042
75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:
I know of no databases with a ZipCode type. Strings are the way to go.

SAS has, but since it uses the US Zipcodes(?) I have never used it. In Holland
the zip code has this format: dddd AA
with d being a digit and A being a letter, for instance: '2552 XZ'.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66304
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
SAS is not a database along the lines of Oracle, PostgreSQL, MySQL/MariaDB, SQL Server, or even MongoDB. It's an analytical platform suite.
 
Steffe Wilson
Ranch Hand
Posts: 165
12
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I came across a problem once where someone was storing phone numbers as ints. Aside from the fact that int is not big enough to store international format phone numbers an int is not an appropriate type.

A key point to remember is that numeric types have operations associated with them that are relevant to mathematical operations, eg add, subtract, multiply, divide, greater-than, less-than. Would it make sense to apply these operations to a zip code or to a phone number? Would you ever want to multiply two zip codes? Or add two phone numbers? If not then the type is inappropriate.


 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:And with regard to "Strings are bad", be wary of taking a knee-jerk approach to applying such admonitions everywhere. Think of it as "Strings are bad when using them for things that aren't strings"

And I disagree, at least for this case. A zipcode is not a String; it's a "String with rules" - and in my book, that makes it a type.

The fact that SQL doesn't have a Zipcode type is irrelevant. Neither RDBs nor SQL were ever designed to be object-oriented, and we're talking about Java here. It should be perfectly possible to write a Zipcode class that can convert to or from an existing String; and if you have a type, it should be reasonably simple to have middleware like Hibernate do the conversion for you with appropriate annotation.

Making it a class also allows you to break it down into its constituent parts (oldZip and suffix?) if you need to, and incorporate any rules - including formatting ones - that apply to either (I seem to remember, for example that oldZip can't be 0; and I'd care to bet that there are also some "special use" ranges).

Where I would agree with you is that it probably doesn't matter too much whether you store the parts as Strings or numbers (although I have a slight preference for the latter), but IMO the whole thing is definitely a specialised type, and not simply a String.

My 2¢.

Winston
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:it probably doesn't matter too much whether you store the parts as Strings or numbers...

I just had a quick browse of the USPS site, and one thing that suggests that it might be better to store the 'oldZip' portion as a String is that the first three digits have special significance: The first digit (0-9) is a "region", and the next two denote a "population centre" and, while it would be perfectly possible to extract them from a number, having it as a String makes the code crystal clear.

I still say that a zipcode is not merely a String though.

Winston
 
Campbell Ritchie
Marshal
Posts: 56529
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:. . . I know of no databases with a ZipCode type. . . .
Nobody had said anything about databases. Here on BJ people should be learning to create classes to model their data. Strings would be a good way to store the code (the format of zip and postal codes varies from country to country) but for a simple 5‑digit number I can see another possibilityVerification is possible with Strings too, possibly with a regex, but I haven't bothered to work out how. Well, "\\d{5}" possibly, and not equal to "00000".
 
Steffe Wilson
Ranch Hand
Posts: 165
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Bear that zip codes should no-way be stored as ints. They are identifiers not numbers, like I said above. I can see no justification whatsoever for storing as int.

I also agree with Winston and Campbell (his earlier post was more explicit on this) that zip code warrants a class/custom type. If they are destined for database storage after all, then the class can provide encoder/decoder for appropriate representation for this purpose. Once you've encapsulated the zip code in a class you can tweak the underlying storage type as required. My first version would be String. There may be cause to modify the internal storage type later as one discovers finer details of the official zip code definition / required validation but that is ok because all that stuff has been safely encapsulated. Text book case for a class in fact.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steffe Wilson wrote:They are identifiers not numbers, like I said above...

And even then, they aren't simple identifiers. For starters, there are two forms: ZIP and ZIP+4, so is 10022 an identifier or a group that covers any ZIP+4 starting with those digits? I suspect it could be argued either way; and if it's a type, you can have Comparators that handle it either way.

Winston
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!