Re: i18n'ed Character Set in DBMS and tables
From: Albretch (lbrtchx_at_hotmail.com)
Date: 09/06/04
- Previous message: Lee Fesperman: "Re: Thread synchronization"
- In reply to: Mark Yudkin: "Re: i18n'ed Character Set in DBMS and tables"
- Next in thread: Mark Yudkin: "Re: i18n'ed Character Set in DBMS and tables"
- Reply: Mark Yudkin: "Re: i18n'ed Character Set in DBMS and tables"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 5 Sep 2004 17:24:49 -0700
"Mark Yudkin" <myudkinATcompuserveDOTcom@nospam.org> wrote in message news:<chfb5k$1bn$1@ngspool-d02.news.aol.com>...
. . .
> You don't. I18n is designed to permit you to SELECT ONE SPECIFIC language
> and process that correctly. To store and retrieve "ALL" languages, you use
> Unicode.
. . .
Well, I see 'issues' right there. I think your approach to it is
wrong 'by design and implementation' and this is what I am trying to
avoid.
Let's say you can set the character set and collation all the way
down to the column. Now, if you 'use unicode to store and retrieve
"ALL" languages' (as you suggest) and since, naturally and per SQL
ANSI's spex, you can only set a character set and a related collation
on a column (and AFAIK (and I could see why it is not so) you can not
specify/change collation on the fly as you run a 'select' query with
an 'order by' clause)
Unless in Unicode, which by the way I see as a good technical example
of a waste by trying to keep extensively ASCII'ing all nat langs (this
is the weakest/silliest 'standard' I know of), collation is not
necessary since there is a 1=1 map between character set and collation
orders for all langs which to me sounds really unnatural
Say you have Korean names and Swahili ones in a table, do people 'use
unicode to store and retrieve "ALL" languages and since' and then keep
an extra columns specifying the character set, . . . and then 'SELECT
ONE SPECIFIC language and process that correctly' a la':
SELECT SrName, FName from NamesTable
WHERE(CHAR_SET_Col='Korean_CHAR_SET') SORT BY SrName, FName;
and/or
SELECT SrName, FName from NamesTable
WHERE(CHAR_SET_Col='Swahili_CHAR_SET') SORT BY SrName, FName;
this would be -way- slower than having the two tables collation
sensitive columns set to the correct char_set + collation pair,
keeping an index on them and periodically physically sorting them.
Or?
- Previous message: Lee Fesperman: "Re: Thread synchronization"
- In reply to: Mark Yudkin: "Re: i18n'ed Character Set in DBMS and tables"
- Next in thread: Mark Yudkin: "Re: i18n'ed Character Set in DBMS and tables"
- Reply: Mark Yudkin: "Re: i18n'ed Character Set in DBMS and tables"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|