- - PR -
nvarcharについて
1|2|3
次のページへ»
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2004-11-30 19:38
いつもお世話になっております。
現在ASP.NET(vb)、SQLSERVERにて開発を行っています。 nvarcharを使用しようと思っているのですが、 何か問題とかあるでしょうか? これまで使った経験がなく少々不安があります。 どなたかご教授ください。 よろしくお願いします。 | ||||
|
投稿日時: 2004-11-30 21:13
どういうことが不安ですか?たぶん、「こういうことが不安なのだが」と聞く方が早い。
| ||||
|
投稿日時: 2004-11-30 22:16
まぁvarcharとnvarcharの違いはShift_JISかUnicodeかっていうことですよね。
全角2バイト、半角1バイトとかって言う古い概念がvarcharで、文字は文字数だけっていうのがnvarcharとおもえばよろしいかと。 あいう123はvarchar=9, nvarchar=6となります。 _________________ 中博俊 (MSMVP Visual Studio C# Since 2004-) http://blogs.users.gr.jp/naka/ naka@wankuma.com VisualStudio2005のすべてのエディションにUnitTestを。投票募集中↓ http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackId=FDBK173 [ メッセージ編集済み 編集者: 中 博俊 編集日時 2004-11-30 22:18 ] | ||||
|
投稿日時: 2004-12-01 08:56
お返事ありがとうございます。
これまでほとんどの場合でvarcharを使用していて nvarcharを使った事がなかったので、 データ書込み・抽出等、処理全般において varcharと変わらず処理されるのか疑問に思っています。 | ||||
|
投稿日時: 2004-12-01 19:02
バイト数に依存するような書き方をすると、問題がありますね。中さんが書かれているように、Unicodeでは文字数でカウントするので、逆に文字数制限などで楽になると思います。いや、「10文字っていっていたから、半角だと20文字はいるはず」などと、余計なことを考えるヤツがいるかもしれない。そういう数(かず)に関する誤解を除けば、Windows端末から読み書きする分には、何も問題はない、むしろvarcharにしてShift-JISとUnicode(プログラム内)で変換する方が、問題があるように思います。
_________________ | ||||
|
投稿日時: 2004-12-02 09:47
おはようございます。
お返事ありがとうございます。 ・開発者のプログラミングの仕方 ・数に関する認識 等の問題はあるしても特に問題はないようですね。 ありがとうございました。すっきりしました。 nvarcharを使おうと思います。 これからもよろしくお願いします。 | ||||
|
投稿日時: 2004-12-02 12:59
本当に余計なことかな? 技術的な問題はないかもしれないけど。実際には「半角は文字幅が半分だから 2倍入力・表示できる」という発想は顧客側に根強く残っていて問題になることがあります。 プロポーショナルフォントが当たり前のように使われるようになってきたので Excel や Word を使っているフツーの人達は、半角を使うと 2倍入力できるという発想はもはや持っていないはずだ! と私も思っていたことがあります。 でも実際は違いました。業務系ではいまだに「半角は幅が半分」なのです。たとえば、マドあき封筒に入れる請求書の宛名欄。長いビル名を半角にして詰め込んでいるのです。プロポーショナルフォントを使うわけにはいかない。バイト数でなく文字数で制限すると、ハイカラな長いビル名がそもそも入力できなくなってしまう。 一般的に 漢字表記よりもアルファベット表記・カタカナ表記のほうが長いものが多いのです。たとえば、人名。全角10文字(20バイト)の氏名欄。日本人ならほとんど問題ないのだけど、外国の方の名前を入力しようとすると、10文字では足りないことがほとんどなのです。 それじゃあ、はじめから Unicode 20文字にしておけって? そうすると、全角で日本語を入力すると、かなりの長さ(表示幅)の文字列が入力できてしまうのです。これは帳票設計や画面表示で印字幅を確保するのが非常に困難になります。 技術的な動向はともかく「半角は幅が半分」というのは今でも重宝されていたりするわけです。私もできることなら nvarchar だけで設計したいのですが、泣く泣く varchar で実装することも多いです。今はユーザー定義関数で LenB() や LeftB() を作っているので、昔ほど varchar を使っても苦労はしないですけどね。 nvarchar/varchar の選択は、技術的な理由だけでなく業務適応性も考慮することをオススメします。VB のテキストボックスの MaxLength プロパティが Unicode 文字数での判定だから… などの安易な理由で nvarchar を選択するとヒドイめに遇います。 | ||||
|
投稿日時: 2004-12-02 15:20
お返事ありがとうございます。
ご指摘の通り安易な理由でnvarcharを使用しようと思っていました。 情けない・・・ 確かに帳票や画面構成等でムダ(?)に確保することが必要になりますね。 業務適応性については考えていませんでした。 まだまだですね。 コロコロ考えが変わりますが、varcharを使おうと思います。 ありがとうございました。 |
1|2|3
次のページへ»