Post reply

A Tiny Trauma

  • February 13, 2019 at 1:48 pm

    #2022004

    n.ryan - Wednesday, February 13, 2019 10:50 AM

    Eric M Russell - Wednesday, February 13, 2019 7:35 AM

    Rather than measurements and counts, I think that TINYINT was intended as a more storage efficient datatype for low cardinality numeric columns like: GenderCode, StatusID, or AgeGroup. My own table designs tend to contain a generous amount of TINYINT, CHAR(1), and DATE columns, because I understand that the limitations of the data types still meet the use case requirements, and there is no point is wasting storage space and memory.

    That's a good point. I work on the same principles of minimising the data type to the requirements of the data. If later the column data type needs to be changed this can always be done, although I'm still waiting on MS to implement column data domains (introduced in SQL-92 IIRC)...

    Yes, I also heavily use constraints. There is a T-SQL feature called a RULE which works like a DOMAIN, but it has never been widely used and is currently considered deprecated.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • May 23, 2022 at 12:15 am

    #4037304

    Since you don't keep type 2 dimensions, would it be better to store the retry limit in the log table. That way you'd know what the limit at the time was and there is no need to change the datatype for any column. You end up with the same amount of bytes taken up compared to changing to smallint.

Viewing 2 posts - 16 through 16 (of 16 total)

You must be logged in to reply to this topic. Login to reply