On 16/11/2006 8:57 AM, Terry Reedy wrote: > "John Salerno" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> John Machin wrote: >> >>> Here in Austraila, (I expect this is common to most countries), there >>> are people who are utterly clueless about elementary data model rules, >>> like identification "numbers" should be kept as strings. >> Do you mean that ID numbers that serve as a primary key in a database >> should also be strings? > > If you mean user-entered data like social security, phone, account, part, > or postal code 'numbers' -- as opposed to internal db-generated numbers > that the user never sees -- this I would presume 'yes'. > > tjr
Clarification: A db-generated number like ROWID etc should be whatever the db makes it. An identification "number" like social security number etc should be a string, irrespective of (a) whether the user entered it or a script entered it and (b) whether it's a primary key, foreign key or no key at all. Some "numbers" contain characters outside [0-9]: e.g. ISBN (base 11, "X" means 10); Hong Kong ID card "number" (base 36 in some positions). Even if all bytes are in [0-9], a simple rule should be applied: Does it make sense to add or subtract such "numbers"? The answer with (SSN, phone number, account number, postal code) is no, so don't store it as a numeric type. Cheers, John -- http://mail.python.org/mailman/listinfo/python-list
