• I agree with the Gail's point. I describe myself as an analyst rather than a DBA or a developer and I would agree: Keep it Simple (S)! Certainly never try and be "clever", because if you are, then you can be sure it will come back and bite you or someone else.

    It is true that telephone numbers are "numbers", but a lot of people provide them formatted with spaces or dashes (0123-123-4567) and who are we to tell them they are wrong? If we really care that much that we want to exclude invalid characters then I suppose one could provide a constraint, but then what about the companies who have numbers which they have gone to the trouble of choosing their number to make a point (0800-SQLDBA)? The whole point is that what people remember is the letters.

    Postal Codes are another example where unnecessary restrictions are sometimes applied. USA Zip codes and Russian codes are all numeric. I learned from Gail's piece that South African ones are numeric with significant leading zeros. British post codes are alpha-numeric with a particular structure (AB12 34XY but with exceptions).

    Too often people don't put enough thought into choosing the datatypes. When in doubt I try to talk to a DBA who is experienced with the database manager we are going to be using.

    As for "weirdest", this one wasn't weird, in fact the choice of datatype was appropriate, but it was funny (or at least my reaction was). I had a job looking for data errors in a production database (I had access to a redacted copy etc etc). The transaction or account values were held in columns which had been defined with a type of CURRENCY (or something like that). l found a candidate error in the production data and nearly had a heart attack! After a few deep breaths, and before pressing the "big red alarm button", I went and spoke with the application support people and they put me right. I had found a real candidate error, but the accounting application worked in "pennies" not "currency units" (Euro/Pounds/Dollars), so I had seen the error as being 100 times bigger than it actually was! It turned out the error had actually been trapped by the application anyway, so it was all ok in the end, but I think I lost some weight that day.

    Tom Gillies LinkedIn Profilewww.DuhallowGreyGeek.com[/url]