[KLUG Programming] questions on picking data types

[Adam Tauno Williams]

> > I'd just store it as a string.  Since a SSN isn't really a number,
> > even though it is composed of all digits.  Otherwise you will have
> > problems with SSN's that *START* with a zero (an INT field will obviously
> > drop it). Like a phone number isn't a number.  And while you may store
> > SSN, how often do you ever actually look someone up using SSN?
> We will actually need to look people up by SSN.  We do not need to
> sort by SSN though I don't think.  I wonder if I use the string that
> I could put three fields on the form and constrain them for the
> appropriate number of characters and then concatenate them into the
> field on the write of the data?  

Sure, the exact method depends upon the widget set used by the
programming environment,  I've never used RealBasic.  Under GTK# for
example you'd just implement exit event handlers for each entry widget -
those functions would read the three entry widgets and update the value
of the SSN variable.  (An exit event handler gets invoked whenever focus
[the cursor] leaves a widget).

> I am just worried that I am going to
> get one that is typed in as 123456789 and another 123-45-6789 and
> another 123-456789 and a forth 12-34-56789.  There are way to many
> permutations for efficient error trapping I think... well unless I
> strip out all hyphens and then re-input them as needed. 

You're right, they're are several correct ways to do this.

>  I think I
> would want to store the hyphens so that once I capture the SSN I do
> not have to continually write code to format the number properly
> every time I need to display it in a form or report.

Good, OO can help solve this.  Create an object "client" that handles
all the formating, trimming, etc... and use that object from your client
applications

<Database>--<OO Layer>---<UI/App>

The more complex your app becomes the bigger the return for doing the
additional up-front effort such a design requires.

I don't know about the extent to which RealBasic support OO.   

PHP5 looks like it finally supports real OO work, verses PHP4's
murderous object-same-as-a-scalar behaviour.

While the multi-layered approach is in some sense more complicated, it
is also in many ways easier to debug and maintain.  If UI's are just
that, UIs, and don't do logic work running down where an error condition
stems from gets ALLOT easier.