Arne said:
Row alignment in a database ?? That sounds about as good an explanation
as the moon !
I've never seen a real-world case where it was an issue, but it's far from
inconceivable. CPUs still access aligned data faster than unaligned data, so
aligning your data on disk may ultimately align your data in memory in such
a way that there's a benefit. On the other hand, of course, increasing your
row size increases the number of pages, which in turn can adversely affect
performance. So I'm not tuning my tables for alignment just yet...
But even if it do happen, then the fact that it could be because of
a fundamental change of type makes cast better than the Convert.
It doesn't matter what might be the case, it matters what the case is. Your
talking in absolutes makes me uncomfortable.
If the change is a "fundamental change of type", in that the field now
stores *more* than a boolean value, then the cast was a good idea because
the code will obviously fail. It should fail because otherwise we might
silently accept bad data, which could lead to corruption. Our code is good
because it did not rely on the database being correct. We now have outage,
but that's better than corruption.
If the change is not a "fundamental change of type", in that the field
*still* stores boolean values, just in a different size on disk, then the
cast was not a good idea because the code will obviously fail. It should not
fail because there is no bad data, no more than there was before. Our code
is bad because it did not rely on the database being correct. We now have
outage where we could have continued running.
If the program chooses to define "boolean stored in a table" as "any
integral type with values of 0 meaning False and values not 0 meaning True"
then it may behave unexpectedly if someone doesn't realize that that's how
things work. This is a viable solution, but it may not be optimal in all cases.
If the program chooses to define "boolean stored in a table" as "a TINYINT
with 0 meaning False and 1 meaning True and anything else being an error"
then the program will require maintenance if the underlying type of the
field is changed, which forces us to check if everything still works
correctly. This is a viable solution, but it may not be optimal in all cases.
Best of *all*, in my opinion, is if the program cannot have this problem in
the first place because it has hard guarantees that the data is delivered as
BIT. If this is made part of the database interface, it's no longer our
concern but the concern of the database hackers. Unless we are also the
database hackers, but you get my drift.
