Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re: SSN's possible new Y2K problem?

by clintp (Curate)
on Aug 14, 2002 at 00:26 UTC ( #189958=note: print w/ replies, xml ) Need Help??


in reply to SSN's possible new Y2K problem?

First, to disagree with tye's blanket statement, using "SSN" as a field description is sometimes quite appropriate. For example, I work in the US Payroll industry. Without an SSN (or an IRS ITIN, same format) you are virtually not employable: the employer cannot report your wages to the IRS, nor can they file their own paperwork, and the SSA cannot maintain their wage and earning records. (Remember, "contract" employees aren't really "employees" count for Payroll purposes.) An "ID Number" would be a completely inappropriate replacement for this field.

Short history of the SSN

If you think about it, until recently not everyone needed a SSN. At some point, not everyone needed an SSN: those not eligible (foreign workers depending on status prior to 1986, 1981, 1977, etc..), all of those stay-at-home parents who never worked or filed prior to 1988, any wage earner who chose not to participate prior to 1962, children prior to 1988 (and unclaimed dependants even now), and so on. So the SSA has only issued 140 million SSN's over the past 70 years. Don't get caught in the mental trap of using the SSN against population as an ID number, it doesn't quite work that way. It's not 1:1, and not even 1:N where N is constant over the last 70 years.

They've got plenty left for a while to go. Not another 70 years for sure, but for a while.


Comment on Re: SSN's possible new Y2K problem?
Re: Re: SSN's possible new Y2K problem?
by demerphq (Chancellor) on Aug 14, 2002 at 13:25 UTC
    Er, well since you work for the US payroll industry I can see why you would say what you say. But I still think that tye is actually right and you are wrong. His comments about international issues are particularly relevent. For instance I work for an US headquatered company with a very international presence. For quite a while we in Europe were unable to obtain even basic service from the US company because we had no SSN. In fact their comments when the subject was raised usually amounted to a suspicious "How can you work for us if you dont have a valied SSN?" "I work in europe" "And you dont have a valid SSN?" *sigh*

    Consider a more flexible design: two tables, one that contains the definitions of various form of ID (such as US-SSN CA-SIN UK-whatever ...) which is referenced by the table that stores the IDS, in other words your US centric SSN becomes a two part ID, the SSN itself and the type of ID that it is.

    Yes of course this would mean that your software becomes slightly more complex, but then again its market potential goes from 270Million to the worlds population of 6 billion. A small tradeoff I woudl say.

    As a developer in an international company, with a North American origin, I am constantly amazed and amused at how often my North American colleagues make design decisions that mean their software is utterly unflexible in other enviornments and is utterly mated to a fixed NA concept of how to do things (and correspondingly useless outside of those areas). Examples include area codes, phone numbers, addresses, billing regulations, tax codes and the like. Designing your software to be properly flexible for alternate operating enviornments can only be a plus. An example is this: at some point (2-5 years maybe?) all of you in NA are going to have to go through something horrible, a telephone renumbering. (the UK monks will remember their (two!) experiences with this in recent years) This will involve adding at least one digit to every North American phone number, most likely but not necessarily the area code (a common approach has been to do away with the useful and convenient but unscalable fixed length area codes and go with flexible length area codes, this minimizes the number fo people who have to relearn phone numbers, as only the area code changes). So ask yourself this, of the code that you have been involved in, how much would have to be rewritten if this was to happen? How much extra work would it have really required to design your software so that it was flexible in this regard from the very begining? And ask yourself the most important question: which would have been cheaper?

    Yves / DeMerphq
    ---
    Software Engineering is Programming when you can't. -- E. W. Dijkstra (RIP)

      Flexibility has its uses, but it shouldn't be the ultimate goal. To make a good product means more than decreasing potential future modifications. For a software product, there's also a business interest, and there usually happen to be users as well.

      To make a table as flexible as possible, you'd make every column BLOB, GBLOB or whatever your favourite database has. Then you can store anything in there, and lots and lots of it!

      But it's better to stop and think "why in the heck am I using a database in the first place"? Because you have valuable data. Data that might be more valuable than programmer time. People (and programs) need to access the data, trust the data to be correct, and they need to be able to access it fast. The stricter the better. If you have an SSN column of maximal 9 characters, it's not possible to stuff 10 chars in it - the database will reject it. You can put "gooble" in it, and that's why a numeric field would be better. Speed can also be an issue. The smaller a row is, the more fit in a page, and the faster access will be. Also, the smaller your database is, the faster backups (and not unimportant, restores) will be. Don't get the idea diskspace is cheap, sure a disk at your local PC store doesn't cost a lot, but if you have to house it, mirror it, backup it and pay the person doing all this, the cost no longer is insignificant.

      Flexibility is a trade off, and especially with database more flexibility can easily mean a significant price you have to pay in speed and size.

      Abigail

      Greetings!

      First let me agree with Abigail-II: "Speed can also be an issue." Speed is a big part of what a database is all about.

      Certainly, the relational model gives us flexibility and reuse of data, but speed can be the cost. If we were to use a table to define the "ID number" types, we move towards a more normalized form. The problem is in overextending ourselves in this way. Normalization can be taken to the extreme.

      Moderation is a key them when deciding on the level and detail of normalization in a database. Many monks from other monasteries have preached the benefits of moderation. Many DBA's would include themselves in that bunch. Joins can become quite a task when every field must be validated against typing tables.

      Regarding SSN's: I think we still have a while before we reach the point of needing additional or different base numbers. Regardless, I've oft wondered at things like SSNs, IP Addresses, Credit Card Numbers, etc. When adding intelligence into the code, like Credit Card Numbers, we greatly reduce the number of possible variants.

      By the way... when will a pin be required for the use of my SSN?

      -Daruma

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://189958]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (7)
As of 2014-10-25 16:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (146 votes), past polls