Re: Newbie question about BIGINT and INT in the same table

On 10/28/2019 9:17 AM, Lyle H. Gray wrote:
> Jerry Stuckle <jstucklex_at_attglobal.net> wrote in
> news:qp5ij4$9l$1_at_jstuckle.eternal-september.org:
>

>> On 10/27/2019 11:47 AM, Lyle H. Gray wrote:
>>> Jerry Stuckle <jstucklex_at_attglobal.net> wrote in
>>> news:qp4bqs$q6t$1_at_jstuckle.eternal-september.org:
>>>
>>>> You do NOT want to store numeric data as strings.  For one thing,
>>>> sorting will be crap. '2' will be larger than '15'.
>>>
>>> Agreed.  If you want to limit the value size with a length, rather a
>>> specification of storage used (e.g. as TINYINT, SMALLINT, INT,
>>> BIGINT), then use a fixed decimal datatype (NUMERIC() for whole
>>> numbers, DECIMAL() otherwise).
>>>
>>> If you _do_ use VARCHAR() for storage of numbers that you want to be
>>> able to sort on, you would need to have leading zeroes (e.g. '002'
>>> instead of '2').  That's usually adding complexity that you don't
>>> need.
>>>
>>
>> Not to mention you'll also have to search for '002' instead of 2.

>> But there are better ways than using a decimal type - i.e. triggers to
>> limit the range of values.

Yes, for something as simple as this a CHECK CONSTRAINT would work fine.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex_at_attglobal.net
==================