Various Topics on Java

..bret..

.. Can you define the Character Set for particular tables instead of
databases?
. Which DBMSs would let you do that?
. How do you store in a DBMS i18n'ed users' from input, coming over
the web (basically from everywhere) store it and properly serve it
back to users, . . .?
. Can you point me to info on this?

I would preferably use Java/JDBC drivers.

.... ..t..

Albretch wrote:

> . Can you define the Character Set for particular tables instead of
> databases?

Yes, sometimes in the entire world of computer science, but since you have
cross-posted so widely, you need to choose a single newsgroup and ask again
for a specific answer.

>**.*Which*DBMSs*would*let*you*do*that?

That depends.

>**.*How*do*you*store*in*a*DBMS*i18n'ed*users'*fro m*input,*coming*over
> the web (basically from everywhere) store it and properly serve it
> back to users, . . .?

Unicode. Choose one newsgroup, make one post.
--
Paul Lutus
http://www.arachnoid.com

.... ..dk..

"Albretch" <lbrtchx@hotmail.com> wrote in message
news:f8544ad2.0409050549.1164b015@posting.google.c om...
> . Can you define the Character Set for particular tables instead of
databases?
Depends on the DBMS
> . Which DBMSs would let you do that?
Various. With such a m***ive crosspost, there's little point in anybody's
answering with any specific set of DBMS's
> . How do you store in a DBMS i18n'ed users' from input, coming over
> the web (basically from everywhere) store it and properly serve it
> back to users, . . .?
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.
> . Can you point me to info on this?
www.unicode.org
>
> I would preferably use Java/JDBC drivers.
Many databases support these APIs.

..bret..

"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?