"datatypes which are always UCS-2"
You have to be careful with Oracle because you can only use the UCS-2 subset
of UTF-8. The Oracle CLOB is also stored as UCS-2 not UTF-8. One of the
problems with UTF-8 is field sizing, as the fields must be sized in UTF-8
bytes not characters.
There are advantages and disadvantages of Oracle and SQL Server.
From: Tague Griffith [mailto:firstname.lastname@example.org]
Sent: Monday, January 29, 2001 6:33 PM
To: Unicode List
Cc: Unicode List
Subject: Re: [OT] Unicode-compatible SQL?
My recomendation for using Unicode with a database would be Oracle.
Oracle supports Unicode (as UTF-8) quite well and has the language data
for many locales as part of the universal install. I also prefer that
it is easier to configure the database character set independently of
the OS localization and that you aren't limited to using nvarchar,
nchar, etc. datatypes if you want to use Unicode.
SQLServer also has Unicode support through the use of nvarchar, nchar,
etc datatypes which are always UCS-2. SQLServer will probably be a
cheaper and simpler option to install (although i don't find the Oracle
install all that complex).
Unfortunately, MySQL currently doesn't support Unicode, possibly in a
Elaine Keown wrote:
> A friend who is off-list asked me to inquire about Unicode-compatible SQL
and database options. He has been told that Microsoft SQL is now available
in Unicode, but he usually uses the Macintosh. What other options are there
now in the various kinds of databases, probably on the smaller end of the
> He's interested in the database having the capability of having a Web
front-end--I think that's absolutely critical for him. He's doing Hebrew
and a tiny bit of Aramaic in his project, so I think he would need at least
Unicode 2.0 compatibility, with Unicode 3.0 the best choice.
> Elaine Keown
> Find the best deals on the web at AltaVista Shopping!
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:18 EDT