This is the only part I really have a comment on...

>
> By that logic, an index is also a normalisation failure. You do not
> actually need an index to do any function, it is simply a
> representation of the actual table data that can be used to speed up
> operations such as conditions, joins and sorts.
>

This is false, because an Index is not a data field. You don't select an
index. You dont insert values into an index. It is a behind-the-scenes
mechanism to make your RDBMS work better.

I think there is a misconception that I feel that the solution I
presented was optimal. I certainly wouldnt use it unless it was for a
table I know was going to not be stored in often (because retrieval of
the data wouldnt be affected), but on the same note, I wouldnt implement
something one way, then be inconsistant elsewhere.

My grief was simply that the UPPERized field violates normalization. It
does. Justify it all you want, but it does. Now that doesn't mean that
this is a bad thing. We all have been in situations where circumstances
for one reason or another has forced us to do something rediculous. But
dont throw good practice to the wind for the sake of speed or simplicity.

Jason