October 22, 2015 at 10:11 pm
Comments posted to this topic are about the item Positive or Negative
October 23, 2015 at 1:54 am
I am definitely in the 'IsActive', 'IsCurrent' camp.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
October 23, 2015 at 2:01 am
I always try and use IsActive with 1 for Yes and 0 for No (Default 1, Not NULL) and save it as a Bit / Boolean data type.
Obviously when it's not a straight Yes / No or On / Off then usually a Char(1) Not Null Default 1.
David Grant
October 23, 2015 at 2:03 am
"IsActive" or "Active" or suchlike - 1 when it is active and 0 when not.
I have seen a column that is "NotActive" with a value of 0 to indicate that it is active. In my mind this is a double negative and makes it more complicated than it needs to be - especially if there a few indicators like this in the same query. How easy is it read something that keeps referring to "Not NotActive"?
October 23, 2015 at 2:03 am
I suggest it depends on intent. If the intent is that the user must explicitly acknowledge that it is active then I would go for the positive approach. If the records are normally inactive and only some become active then I would use the negative approach.
October 23, 2015 at 2:08 am
The negative form leads to difficulties with double negatives (if isInactive = 0). The positive form is much clearer.
October 23, 2015 at 2:12 am
I have always used a column called Active with a value of 1 for active and 0 for inactive. I find it much easier to think in terms of a 1 being true and 0 being negative, I think the term is positive logic, and I think it makes the code more intuitive to understand.
October 23, 2015 at 2:12 am
I prefer notation, described in post.
If state of record considered as normal, it should be "0". I use value "1" for special condition.
For example:
Correct:
Default state of record: Deleted = 0
Manually switched or coused by special event state: Deleted = 1
Incorrect:
Normal user account: IsActive = 1 by default
Banned user account: IsActive = 0
October 23, 2015 at 2:19 am
I don't have a preference and I use both. For me it depends on the actual meaning of the flag and the default value. Usually I will choose the name that will make the default value 0 (=No). For example are the records normally active? If so then I prefer "Inactive" or "IsInactive" or "Disabled" as it clearly shows which state deviates from normal.
Sometimes I may use one or the other to emphasize the meaning.
Rarely I may choose the one that makes most expressions simpler to code. For example if I commonly check if something is inactive in order to do some special processing or filter, but the opposite is not true, I prefer IsInactive. If OTOH I usually check for something being active (e.g. return only active records) then I prefer IsActive. Regularly using negations (NOT IsActive or IsActive=0) is error prone.
October 23, 2015 at 2:37 am
I predominately work in the data warehousing space and adopt an alternative approach which takes out the aspect of either 'Positive' or 'Negative'. For example, a fact which measures the change in activity on a record, would have a "StatusKey" that links back to a dimension containing the actual values "Active", "Inactive" as well as a couple other relevant statuses (such as "Deleted" to track those pesky removals from the source data).
October 23, 2015 at 2:59 am
I am firmly in the "flag exceptions" camp. So normally I have columns like [disabled], [exclude], [unsubscribed] which default to zero, and are set to 1 to mark the exception. This is the way many operating systems and languages have always worked: 0=nothing to report, non-zero means some kind of exception / error.
I always try to name the column for the exception condition. For example, if the normal condition was "inactive", my column might be called [active] with a default of zero. If the normal condition was "active", my column might be called [inactive] with a default of zero.
Consistency is good, as is using a limited set of verbs for these column names, and always trying to use the same verb for the same kind of exception across the whole database. (i.e. do not mix-n-match synonyms)
October 23, 2015 at 3:31 am
Not exactly an answer to the question, but I use a field named State, Status, or Condition.
VARCHAR(1), Default '' (an empty string).
I fill this field with a Char when the Status is "not normal", e.g.
e = ex client
i = ignore client (the client doesn't want any contact: e.g. client deceased)
u = undesirable (we don't want that client any more: payment problems, etc.)
For normal clients the clause is:
WHERE Status = ''
Active clients are found with a negative flag (Compare an empty string with zero)
October 23, 2015 at 4:22 am
I try to avoid naming Boolean columns as the inverse of their meaning.
It makes for confusion when naming Boolean columns Un... or Not...
I believe that for most people Deleted=True is less confusing than Undeleted=False
Or you could really confuse things by naming columns such as NotInactive (I have seen it done!)
October 23, 2015 at 4:30 am
Fedor 28151 (10/23/2015)
I prefer notation, described in post.If state of record considered as normal, it should be "0". I use value "1" for special condition.
For example:
Correct:
Default state of record: Deleted = 0
Manually switched or coused by special event state: Deleted = 1
Incorrect:
Normal user account: IsActive = 1 by default
Banned user account: IsActive = 0
I agree with you, it depends on the case. However, when I am in doubt I choose IsActive. Also, I prefer to use IsActive than Active
October 23, 2015 at 4:35 am
Henk Schreij (10/23/2015)
Not exactly an answer to the question, but I use a field named State, Status, or Condition.VARCHAR(1), Default '' (an empty string).
I fill this field with a Char when the Status is "not normal", e.g.
e = ex client
i = ignore client (the client doesn't want any contact: e.g. client deceased)
u = undesirable (we don't want that client any more: payment problems, etc.)
Yike. With an FK to a table to explain what each one means and to prevent illegal values?
Viewing 15 posts - 1 through 15 (of 129 total)
You must be logged in to reply to this topic. Login to reply