 |
|
|
|
The major database vendors are in the business of equipping global enterprises and large organisations with the necessary tools to manage their information. As opposed to operating systems or applications, they could be more properly termed "information management vendors". As a result, they must provide solutions that address the needs of a global environment where any number of languages (and scripts) may be in use.
Since most database vendors produce cross-platform offerings, encompassing different operating systems as well as geographic regions, they must deal with multiple character set encodings, ranging from a dozen or so with Teradata to over a hundred with Oracle [11]. It is inefficient to create a conversion table for each pair of character sets, so a universal super-set is desired.
The SQL (Standard Query Language) database standard specifies that a database system should have the SQL language itself represented in a repertoire of characters, SQL_TEXT [29], that is a superset of all possible characters that the server may encounter. If it is a distributed system, or runs a World Wide Web site, this becomes even more important as the heterogeneity of the clients increases.
The above scenarios imply market reasons to implement Unicode. New means of accessing databases through standardized call level interfaces (CLI) such as ODBC, OLE DB [14], and JDBC (Java Data Base Connectivity) [31] along with the addition of Unicode datatype bindings for each cries a bit louder to implement Unicode. Then there is the issue of portability and performance gains with concommitent reduction in maintenance costs that comes with using a standardized universal character encoding.
The time is ripe with expectant products or newly born Unicode applications. Therefore this survey was created to ascertain, for the benefit of the Unicode developer community, what is being offered to enable information management with Unicode data.
|
|
|