in reply to
Re: Re: SSN's possible new Y2K problem?
in thread SSN's possible new Y2K problem?
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
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.