Re: Indexing by multiple keys
On 03.08.2009 14:46, Arved Sandstrom wrote:
Arne Vajh=F8j wrote:
Robert Klemme wrote:
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
typos.
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.
I disagree.
It comes in as string, it is persisted as string and i can not think o=
f
any operation to be done on it that will not work fine on a string.
It's not that there are operations that would not work on a String. My
point is that there are _too many_ operations that work on a String that =
are either superfluous for a SSN or actually do harm (for mutable
strings). From what I have read a SSN is significantly important and
special enough that a dedicated class is warranted.
It is not particular OO to convert data to unnatural forms.
Whatever "unnatural" means in this context. I find it most natural when =
working in an OO language to model important entities of the real world
as separate classes and not try to cover everything with basic types.
After all, that's what OO is about.
When I stated earlier that I would contemplate Robert's design for an
SSN class if validation was demanded, I would still store the actual SS=
N
as a String, with no structure. I am not sure that Robert was suggestin=
g
otherwise himself.
As you rightly assumed, I wasn't. If Arne's argument were followed,
there would be no point in having other classes as String in an
application at all because all the data comes in as strings and goes out =
as strings. (Of course I am exaggerating here - but just a bit.) ;-)
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/