Decimal() instead of float?

John Machin sjmachin at lexicon.net
Wed Nov 15 21:30:30 EST 2006


On 16/11/2006 8:57 AM, Terry Reedy wrote:
> "John Salerno" <johnjsal at NOSPAMgmail.com> wrote in message 
> news:455b82a0$0$7054$c3e8da3 at news.astraweb.com...
>> 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



More information about the Python-list mailing list