True. Or False. Whatever….

Most of the time, there\’s an understanding between DBAs and their developers. Sure, we all do things a little differently, but we get along fine.

However, when developers don\’t even agree amongst themselves… well, everyone\’s job gets a little harder.

Take a recent experience of mine, for instance. 

Reports were coming in thick and fast about database performance being sub-optimal (a post for another time), but whilst all around were doing heroic things keeping the app afloat, something caught my eye – a function that was being called a few thousand times a minute. Surely something a bit fishy there, I thought.

The function was defined as follows:

create function dbo.ConvertToBoolean
(
   @flagToConvert  char(1) = null
)
returns varchar(5)
as

begin
   return( select case
               when @flagToConvert in (\’Y\’, \’1\’, \’T\’) then \’true\’
               else \’false\’
           end)

Notwithstanding the irony in the name of the function and it\’s output, it\’s typical of what can happen when teams don\’t talk to each other. It would appear that to represent TRUE or FALSE conditions in the database, different people used different things, with 1, Y, and T all being used to express something that has one of two states (like Yes and No, On and Off, Salt and Pepper). This course of action requires something to standardise the meaning.

The moral of this particular story is that a few minutes agreeing how to handle Yes/No-type scenarios would have saved several thousand calls every minute to a function.

Oh, and if they\’d agreed to use a BIT column, that would have been ace, too.