Currently I am justing using Latin1 as Table character set to store
UTF8 data, it work very well.

I don't need those collation stuffs for my data, are there any real
reason I need to use UTF8 as table character set then?

I don't see any benefit but I see some drawback, e.g.

1. Need to set names "UTF8" in each db connection.
2. MySQL UTF8 is just plane 1 support

Any suggestions?

Roy

setesting001@gmail.com wrote:
> Currently I am justing using Latin1 as Table character set to store
> UTF8 data, it work very well.

If you think that's working, you're not testing enough.
>
> I don't need those collation stuffs for my data, are there any real
> reason I need to use UTF8 as table character set then?

If you use ">" or "<" or ORDER BY on those fields, and the
fields actually have UNICODE data in them, the results will be weird.
None of the string operators, like CONCAT, will work right.

If you're going to treat UTF8 data like that, you might just
store it as a BLOB, viewed as opaque by the database. That
locks out all the operations which will do the wrong thing on
misinterpreted data.

John Nagle

Hi

On 6$B7n(B15$BF|(B, $B>e8a(B1$B;~(B45$BJ,(B, John Nagle <na...@animats.com> wrote:
> setesting...@gmail.com wrote:
> If you use ">" or "<" or ORDER BY on those fields, and the
> fields actually have UNICODE data in them, the results will be weird.
> None of the string operators, like CONCAT, will work right.
>

I agree <, > , and order will made stuff not working, so it depends if
you need to operate those operartions on text data.

Some string operations might also have strange behaviour, but I have
tested CONCAT should-be-okay