Jason,

I still disagree on that point. Normalisation is to serve us as
database designers and developers. Generally speaking normalisation
is beneficial. It normally results in less data storage, fewer
duplicate records, faster inserts and updates, fewer record locks to
make a change, fewer resources required to implement cascading
updates and alike. Do not hear me saying that normalisation is bad
because clearly it has benefits.

However, Firebird is not perfect (gasp, watch me dig my way out of
that one). One of the features not implemented (through either lack
of interest, lack of time, or high complexity) is an efficient case
insensitive comparison. Currently, the only really efficient way to
achieve this is to use a surrogate field and index that. Fortunately
for us, Firebird has triggers that means that you do not need to
adjust your queries (unless you are a silly duck who uses select *
everywhere or doesn't specify field names in insert statements). But
a single on line trigger on before insert or before update does all
the messy stuff. When Firebird finally does support something like
case insensitive comparisons using indices, then remove the field.

Now to complicate what would seem like a simple problem, remember
that we are typing in English. English has 26 letters each letter
containing precisely one upper case and one lower cases. Other
languages have other characters that do not have (or have duplicate)
upper / lower case equivalents which makes things tricky.

Look if you want to solve it without adding another field, go for it,
just make sure you don't have too many records in the table. As a
practical solution and it is not workable for tables over 1000
records (which I am guessing will be the case for the original poster)

Adam