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