Re: [Refdb-users] Case sensitivity

[Z F <mai...@ya...>]

Hello Markus,

> I wouldn't call it "logic", but there is a historical reason. The
> author field (and keyword, periodical, and a couple of others) are
> fixed-length fields which are stored in VARCHAR columns, as this is
> the most economical type in this case. Title, notes, abstract and
> other
> fields of unlimited length are stored as binary strings. I chose
> binary over text back then because I *wanted* the search in these
> fields to be case-sensitive.

Ok, so the data are stored differently.

> 
> However, with MySQL 4.1 and later binary strings actually have a
> disadvantage as they don't use the character encoding when it comes
> to
> the sorting order. Using the proper character encoding may actually
> outweigh case-sensitive search (which you don't seem to like anyway)
> these days. I'm open for a discussion how this should be treated in
> the future. In any case, MySQL is quite a mess in these issues.

Using proper character encoding is a good thing which is an argument
for using a text field. Also, in my opinion, searches should be
case insensitive when "LIKE" is used (or at least there should be a 
way to do case-insensitive searches). The reason for this is simple.
A word can be in the begining of a sentance, which means it starts from
an upper case letter. The word could be an acronym, then all letters
are probably upper case. But when performing a search, the user
should not think weather or not, the word my be in the begining or in 
the middle of a sentence. This is the meaning of "LIKE", in my opinion.
"IS" search should probably be case insensitive (or whatever SQL does)
All of this argues for the use of text fields instead of binary ones.
In any case, you word is the last one. :-)

Lazar

PS
As one of the recent US presidents once said: "It depends what word IS
is"... :-)



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com