Re: Indexing by multiple keys

From:

Robert Klemme <shortcutter@googlemail.com>

Newsgroups:

comp.lang.java.programmer

Date:

Sun, 02 Aug 2009 14:58:23 +0200

Message-ID:

<7dlgrlF2b7dp1U1@mid.individual.net>

On 01.08.2009 22:09, Arne Vajh=F8j wrote:

Arved Sandstrom wrote:

Robert Klemme wrote:

On 01.08.2009 16:21, Arved Sandstrom wrote:

Lew wrote:

For the OP's purpose in particular, it makes more sense to model an=

SSN as a String than an int.

In general I agree - I was playing a bit of devil's advocate. I
myself would model an SSN as a string. That the individual 3 numbers=

making up an SSN are not quantitative entities is undeniable. But
then again, neither are ordinal numbers, and both the group number
and the serial number behave like specialized ordinal numbers.

I'm still not sold on the idea that there is a checksum for SSNs. I =

myself don't see how there can be one. You yourself say that the
three numbers making up an SSN are independent of each other.

I would model a SSN as an SSN - meaning: since a SSN is not exactly a=

number and has more properties than a simple length (for example, a
valid format) I would create a class for SSN handling. It's likely
that it will include a constructor with a String (or even
CharSequence) argument but the internal representation does not
really matter. And it can be changed, too if you notice that all of =

a sudden the long you used initially is not sufficient to hold all
the relevant information. My 0.02 EUR anyway.

How I would approach SSN processing (or SIN or credit card number
processing, for that matter) would depend on where I am getting the
number from, and what I need to do with it. For example, a number of
the government applications I am helping to maintain deal with SINs,
but we get them electronically from trusted partners, and so there is =

no need to deal with them other than as opaque strings.

If OTOH the SSN/SIN was being typed in by a clerk I'd consider
validation of some sort. It won't be perfect but it'll catch some typo=

Even with validation String would probably be a better format than
int or int's.

Like matching the string against \d{3}-\d{2}-\d{4}.

I would not want to go with plain String in an OO language if there must =

be validation. IMHO that approach is only justifiable in the light of
performance issues. The default for me would be a separate class with
ensures all the invariants that are needed for an SSN in the application.=

Only if that class is the bottleneck of the application I would consider =

changing this. First line of defense might be to make the validation
optional if that is actually the bottleneck and I have sources that I
can trust. Then I'd consider switching to String. It's easier to
modify a complete program to exchange class SSN for class String as the
reverse operation.

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/