• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Devaka Cooray
  • Ron McLeod
  • Jeanne Boyarsky
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Martijn Verburg
  • Frits Walraven
  • Himai Minh

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

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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" https://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.
 
author
Posts: 23928
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Marshal
Posts: 76888
366
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Sheriff
Posts: 67682
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Sheriff
Posts: 67682
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Sheriff
Posts: 67682
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Saloon Keeper
Posts: 5184
207
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Sheriff
Posts: 67682
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 165
12
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.


 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 76888
366
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
When I was younger I felt like a man trapped inside a woman’s body. Then I was born. My twin is a tiny ad:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic