That sounds like the sort of detail that could change from 1 version of the spec to another. If it's not specified, then I guess it's up to you. Numeric would be more efficient in terms of memory. Personally I think I would go with Alphanumeric, as you know it's not going to get messed about by rounding or dropping leading zeroes. eg. if your number is 000124.500 then it may be displayed as 124.5 so if you are doing numeric, best to start with a 1, not a 0, eg 1000001, 1000002, 1000003 etc.
OK. Well, it's not really specified, but they say it could be the customer's social security number. So I guess my question is, is a social security number numeric, or alpha-numeric? J PS (Guess you can tell I'm not from the U.S.) [ January 23, 2004: Message edited by: Jacques Bosch ]
Originally posted by Jacques Bosch: So I guess my question is, is a social security number numeric, or alpha-numeric?
A Social Security number in the US is numeric only, and is usually displayed in this form: 999-99-9999. Because the format of the customer ID is not really specified (except for length) in the assignment instructions and the supplied-database doesn't contain any customer ID's, I think you can make any reasonable assumption you wish, and as long as you document your decision you should be OK. Hope this helps, George
The id value (an 8 digit number) of the customer who has booked this. Note that for this application, you should assume that customers and CSRs know their customer ids. The system you are writing does not interact with these numbers, rather it simply records them. If this field is all blanks, the record is available for sale.
OK, so it tells me that the number is 8 digits long. In the real world, this probably implies that a check must be made that the entered number is indeed 8 digits long. But then the instructions also state that the system does not interact with this number, but merely records it. So, should I check that it is 8 digits long, or not?