これからの文字項目の桁数

今のところデータベースの文字型項目で容量を考える際、「その項目に必要なバイト数」で領域を定義していると思うんだけど、今後を考えるとこのやり方では非常にマズイというか。

CHARやVARCHAR世代は主にバイト数でカウントする世代で文字コードなんてものは全然考えていない場合が多い。文字コードを考え出して、「バイト数で定義なんてできねーよ」となってでてきたNCHARやNVARCHAR世代は、文字数でカウントする世代だね。後者の「文字数で定義」になれている人ならサロゲートペアがこようと基本は問題ない。
（内部的にバイト数を利用していたりしなければ）

そしてもう一つの問題がVistaより可能になった「UniCode文字結合」。サロゲートペアは「補助として次の16bitを利用する」という1文字＝３２bitな特殊字のことで、文字結合というのは「が」と「か ＋ ゛」は同一に扱うという問題。本当に厄介なのはこっちかも知れない。何しろVistaからなんだから。

対応としては、文字列を扱うときにはカルチャを意識してロジック組まないといけないってことだそうで。文字を結合するのは現状と同じでいいけど、比較するときにカルチャを指定するってこと。これを踏まえると文字列比較用のメソッドを、今のうちに用意しておいたほうがいいってことなんだよねぇ。

ちなみに文字結合はSqlServer2005では対応されている。「が」という文字を検索したとき、「か ＋ ゛」もちゃんと条件にひっかかってくれる。

・・・あれ？てことはNCHARって固定長じゃないの？それとも２文字分使うってことなのか？？