in reply to Re: SSN's possible new Y2K problem?
in thread SSN's possible new Y2K problem?

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)

  • Comment on Re: Re: SSN's possible new Y2K problem?

Replies are listed 'Best First'.
Re: SSN's possible new Y2K problem?
by Abigail-II (Bishop) on Aug 14, 2002 at 14:59 UTC
    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.


Re: Re: Re: SSN's possible new Y2K problem?
by Daruma (Curate) on Aug 15, 2002 at 06:28 UTC

    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?