October 23, 2015 at 1:07 pm
below86 (10/23/2015)
[IsntInactive] = Isnt Inactive = Is NOT Inactive = Is Active? - IMHO that has to be a joke, right? Talking about confusing.It's probably just me but the whole 'Is' part just bugs me. I would rather see a field called 'Active_Flag' or 'Inactive_Flag'.
Yes, I believe Eric's comment was intended to be humorous, as was mine about casting a datetime column to derive his values.
On the serious side, I simply use a column named "Active" and that's it.
October 23, 2015 at 1:08 pm
below86 (10/23/2015)
[IsntInactive] = Isnt Inactive = Is NOT Inactive = Is Active? - IMHO that has to be a joke, right? Talking about confusing.It's probably just me but the whole 'Is' part just bugs me. I would rather see a field called 'Active_Flag' or 'Inactive_Flag'.
Actually the coding scheme is a 64 bit mask of multiple indicators.
IsntInactive & 0 = 0 (default)
IsntInactive & 2 = 2 (active for unknown reason)
IsntInactive & 4 = 4 (set as temporarily active by DevOps for testing purposes in production)
IsntInactive & 8 = 8 (executive management override as active)
IsntInactive & 16 = 16 (user override as active)
IsntInactive & 32 =32 (ignore all other indicators and treat as active)
IsntInactive & 64 = 64 (reserved for future use)
:hehe: No, not really. I made it up to be silly. But we've all seen such similar nonsense on the job, we can't help but think it's plausible.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 23, 2015 at 1:28 pm
On my quantum server, the bit can be both 0 and 1 at the same time.
October 23, 2015 at 1:47 pm
My database server has the new omnistate Solipsistic CPU which insures all bits assume the ideal value desired by each observer at all times.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 23, 2015 at 1:47 pm
This topic takes me back to one of the first professional applications I wrote. The application was a time management system. We where replacing our physical time card with an electronic time card since we where growing beyond our local area.
The issue was related to two enitities within the time card table. They were PUNCH_IN and PUNCH_OUT. Long story short these fields became TIME_IN and TIME_OUT at the end of the project.
October 23, 2015 at 2:26 pm
I used both 'Active' and 'Disabled' as column names for booleans. More often the former but to me they are not antonyms and the opposite of either would not be appropriate or easy to understand. .
October 23, 2015 at 2:44 pm
I would say that it depends on the focus of the column, possibly taking the default action into consideration. Thus, if the default is that the row should be active, then the column should be "IsActive"; otherwise, "IsInactive", or possible something more "positive" like "IsPassive" or "IsDormant"
Still, I would avoid using "Not" in the column name. As with the two examples above, we have either "active or not active" or "inactive or not inactive".
Being a statistician, in hypothesis testing, we will either reject or fail to reject. The alternative is accept or fail to accept.
Christopher Reed, MCT, MCSD, MCPD, MSpec, MTA, MCTS
"The oxen are slow, but the earth is patient."
October 23, 2015 at 3:59 pm
Eric M Russell (10/23/2015)
Rod at work (10/23/2015)
I very much prefer using IsActive, or simply put Active. I am adamant about this because at my previous job the guy who set up the database was completely inconsistent. Sometimes he'd use a column named Active in a table. And then another table he'd use InActive. There was no way of figuring out his reasoning; why he'd use one at one time and then use another a different time. I liked a lot of what he did, but not this. I vowed, whenever I design a database, to always use columns named Active (or I guess I could use IsActive) if I needed a column to notify me as to whether or not a record should be included in a currently active listing, or whatever.However if people prefer to use InActive, I'm OK with that. But just please, for the love of God, be consistent!!!
Sometimes it's useful to have a logical abstraction layer that hides the inconsistent details of naming conventions or functional implementation. For example, create a view called vActiveCustomers around the table Customers. Exactly what filtering or column aliasing is done within the view depends who originally developed the table... or what "standard" the developer chose to apply when she created the table.
That's a good idea Eric, thanks!
Kindest Regards, Rod Connect with me on LinkedIn.
October 24, 2015 at 1:38 pm
Semantically I certainly prefer the positive because it's more intuitive.
Practically though, there are often implications that need to be considered. For instance, how will nulls be treated? We work with Scheme a lot, which treats nulls as true, so we try to make sure true is the safer option, in the same way as circuits are usually designed to default to the safer option (e.g. doors open in case of a power outage).
Therefore I think the real answer is "It depends...". 😉
October 24, 2015 at 6:00 pm
I use the "IsActive" type of thing because 1 is usually considered to be TRUE. I've seen people use negative logic and names before and it's nothing but trouble for most because people don't generally think that way. "IsNotActive" and "IsInactive" are two of the worst column names I've ever come across. The only thing I've see worse in this area is when someone decided that "0" would represent TRUE for such a named column.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 24, 2015 at 6:38 pm
If this is a simple attribute which is rarely to be used as a key filter in queries, then I prefer the "IsActive" approach.
However, if this "IsActive" column is to be used in many queries, I try to avoid columns with only two states (0/1 or 'T'/'F'). Query optimizers usually "prefer" columns with a reasonable distribution of values, so I try to help them by using data types that create a flatter histogram of values. Thus, instead of a simple IsActive column, I would generally use a "TerminatedDate" date/time attribute, with NULL indicating Active (i.e., non-Terminated). This also solves the problem when later the customer wants to get information about inactivations within discrete periods of time, and avoids the de-normalization of having both the flag and the datetime.
October 24, 2015 at 8:27 pm
I'd have to say I'm in the "zero is good" camp and flag the exceptions, so Deleted=0/NULL is a normal row, InActive=0/NULL is a normal row. I disagree that "Not InActive" is a double negative, it's just a different way of stating a logical condition.
October 24, 2015 at 9:29 pm
Kim Crosser (10/24/2015)
If this is a simple attribute which is rarely to be used as a key filter in queries, then I prefer the "IsActive" approach.However, if this "IsActive" column is to be used in many queries, I try to avoid columns with only two states (0/1 or 'T'/'F'). Query optimizers usually "prefer" columns with a reasonable distribution of values, so I try to help them by using data types that create a flatter histogram of values. Thus, instead of a simple IsActive column, I would generally use a "TerminatedDate" date/time attribute, with NULL indicating Active (i.e., non-Terminated). This also solves the problem when later the customer wants to get information about inactivations within discrete periods of time, and avoids the de-normalization of having both the flag and the datetime.
+1000 to the date thing, Kim. I've to often seen a (simplified for sure) "StartDate" and "EndDate" that's also accompanied by an "IsActive" column which "IsInsane" to me. 😛
In that same vein, I try to avoid things like "TerminatedDate" in favor of "EndDate" so that it seems more natural to avoid NULLs in the "EndDate", which allows me to avoid "OR"s when looking for something that may have either a future end date (such as a contract date) or a NULL end date. For those types of things, I try to use just "9999", which implicitly translates to 9999-01-01 and still leaves a couple of days (a year's worth) before I reach the end of SQL Server's date range. This is important because people can't add 1 day to 9999-12-31 to use correct closed/open temporal notation criteria such as...
WHERE SomeDateTimeColumn >= @StartDate
AND SomeDateTimeColumn < DATEADD(dd,1,@EndDate)
That also makes things like Type II SCDs a whole lot easier to write criteria for especially if I'm looking for the latest row (active or not) in such a structure.
When some form of status notation is forced upon me, I do like you do and also avoid "IsActive" in favor of a "Status" column, which can contain a "A" for Active, "I" for Inactive, "P" for Pending, "E" for Error, etc, etc.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 25, 2015 at 9:36 am
I have wondered this myself. I don't believe it makes any performance difference but I will tell you that when one developer uses inactive in one table and another uses active in another table it makes analysis much more difficult. So I would say use either one but always stick with one or the other.
October 25, 2015 at 9:42 am
Viewing 15 posts - 61 through 75 (of 129 total)
You must be logged in to reply to this topic. Login to reply