VARGRAPHICとVARCHAR CODEUNITS32
多くのデータベースをISO8859-1からUTF-8に移行中です。古い文字列を新しいテーブルに合わせるには、3つのオプションがあると考えました。
- バイト数にドメイン内のマルチバイト文字の分布に対応する数を掛け、長さの検証のためのチェック制約を追加します。つまり、CHAR（3）はCHAR（5）になる可能性があります。
- 列をCHAR（3 CODEUNITS32）として宣言します。私の知る限り、これは12バイトを占有します
- 列をGRAPHIC（3）として宣言します。私の知る限り、これは6バイトを占有します。
私は実際には1をオプションとは考えていません。そのため、2と3が残ります。2が3よりも望ましいのはいつですか。一部の文字がCHARからGRAPHICに正しくマップされない可能性がある情報をいくつか見たと思いますが、これはISO8859-1の文字に対しては正常に機能するようです。それ以外に、何か不足しているのですか、それともGRAPHICは常にCHAR CODEUNIT32より望ましいのでしょうか？
GRAPHICデータ型は、広範囲にわたるUnicodeサポートがなかった時代からの名残であるようです。 2バイト文字の保管を容易にするためにありました。本質的にGRAPHIC(3)はCHAR(3 CODEUNITS16)と同等です。
長さのセマンティクス（1バイトと2バイトの文字）は別として(VAR)CHARおよび(VAR)GRAPHICは機能的に同等です。データ型とともに長さの単位を指定するオプションがあるので、GRAPHIC型を使用する理由はまったくわかりません。
UTF-8文字は1から4バイトの間のどこでも使用できるため、固定バイト数の文字の仮定を使用すると、切り捨てまたはスペースの浪費のリスクが発生します。後者を回避するには、アプリケーションで許容できる場合は、VARCHARの代わりにCHARを使用することを検討してください。