MS SQL - Tinyint - Default Value
-
Hi All, Can someone enlighten me as to why you would need a default value of 0 on a tinyint field. I'm not even sure if you do need to set it on all tinyint fields but I was told this by our previous DBA. If the field "Allows Nulls", can it by default be left null without causing any problems? Thanks, JammoD
-
Hi All, Can someone enlighten me as to why you would need a default value of 0 on a tinyint field. I'm not even sure if you do need to set it on all tinyint fields but I was told this by our previous DBA. If the field "Allows Nulls", can it by default be left null without causing any problems? Thanks, JammoD
-
Hi All, Can someone enlighten me as to why you would need a default value of 0 on a tinyint field. I'm not even sure if you do need to set it on all tinyint fields but I was told this by our previous DBA. If the field "Allows Nulls", can it by default be left null without causing any problems? Thanks, JammoD
I don't see saving 1 extra byte per field a relevant issue. I suspect it is an internal convention, default to 0 and the dba/developers/coder/us lazy bastards do not need to test for null values.
Never underestimate the power of human stupidity RAH
-
Hi All, Can someone enlighten me as to why you would need a default value of 0 on a tinyint field. I'm not even sure if you do need to set it on all tinyint fields but I was told this by our previous DBA. If the field "Allows Nulls", can it by default be left null without causing any problems? Thanks, JammoD
-
I don't see saving 1 extra byte per field a relevant issue. I suspect it is an internal convention, default to 0 and the dba/developers/coder/us lazy bastards do not need to test for null values.
Never underestimate the power of human stupidity RAH
If both of the following are true then it could be relevant. 1. High volume system. 2. Many columns of this type. (Really high volumes even a couple might be relevant.) However since the vast majority of systems will never have both of these it isn't going to be relevant.
Mycroft Holmes wrote:
and the dba/developers/coder/us lazy bastards do not need to test for null values.
And maybe a bit stupid too since zero and null are not necessarily the same thing.
-
If both of the following are true then it could be relevant. 1. High volume system. 2. Many columns of this type. (Really high volumes even a couple might be relevant.) However since the vast majority of systems will never have both of these it isn't going to be relevant.
Mycroft Holmes wrote:
and the dba/developers/coder/us lazy bastards do not need to test for null values.
And maybe a bit stupid too since zero and null are not necessarily the same thing.
jschell wrote:
since zero and null are not necessarily the same thing
The is always a debating point, do we allow null to represent a value in a numeric field? As I'm a lazy sod I disallow null in numeric field as my default position and until the business can convince me otherwise that is the way it is designed.
Never underestimate the power of human stupidity RAH