Re: [Nagios-devel] Case-insensitive objects in NDOutils

[Ton V. <ton...@op...>]

On 22 Oct 2009, at 07:25, Hendrik Baecker wrote:


> Am 22.10.09 05:33, schrieb Ton Voon:
>> Quick note. I saw this change below and wondered if this is best  
>> done in
>> the database. For Opsview, we made this change about 2 years ago  
>> for the
>> same effect:
>>
>>    ALTER TABLE nagios_objects MODIFY name1 varchar(128) COLLATE
>> latin1_bin NOT NULL default '';
>>    ALTER TABLE nagios_objects MODIFY name2 varchar(128) COLLATE
>> latin1_bin default NULL;
>>
>> The code then stayed the same. Also it means anything trying to  
>> read the
>> data doesn't need to remember to specify BINARY either.
>>
> Yes it looks nicer and will keep the code cleaner. Also I like the  
> fact
> to keep the work on the database.
> One question back: If it uses COLLATE latin1_bin, the default sort  
> thing
> would be binary which is OK but afaik there are other associations  
> with
> the charset
> (http://dev.mysql.com/doc/refman/5.1/en/charset-collation- 
> charset.html).
>
> What will happen on a simplified chinese as default charset mysql if
> ndoutils would try to set latin1_bin as collate?
> There are missing MySQL international experiences on my side, but is  
> it
> a good practice to rule the charset?
>
> Further comments on this?
> I would prefer a database way to do this, but I wouldn't like to force
> the user to use a charset which he doesn't know/like/can't use.

This is a fair point. Would

    ALTER TABLE nagios_objects MODIFY name1 varchar(128) COLLATE
utf8_bin NOT NULL default '';
    ALTER TABLE nagios_objects MODIFY name2 varchar(128) COLLATE
utf8_bin default NULL;

make more sense then?

Can anyone with more mysql knowledge explain?

Ton