を使用して、学校で小さな Web アプリのデータベースに取り組んでいますSQL Server 2005。vs
の問題については、いくつかの考え方があります。varcharnvarchar
varchar多くの国際化されたデータを扱っていない限り使用してから使用してくださいnvarchar。nvarcharすべてに使用するだけです。ビュー 2 のメリットが見えてきました。nvarchar が 2 倍のスペースを占有することはわかっていますが、これは数百人の学生のデータしか保存しないため、必ずしも大したことではありません。私には、それについて心配せずに、すべてが nvarchar を使用できるようにするのが最も簡単なように思えます。または、私が見逃しているものがありますか？
ディスク容量は問題ではありません...しかし、メモリとパフォーマンスは問題になります。ページの読み取りを2倍にする、インデックスサイズを2倍にする、奇妙なLIKEおよび=一定の動作など
中国語などのスクリプトを保存する必要がありますか？はい、もしくは、いいえ...
そしてMSBOLから「Unicodeのストレージとパフォーマンスへの影響」
編集：
nvarcharのパフォーマンスがいかに悪いかを強調する最近のSOの質問...
常に nvarchar を使用します。
ほとんどのアプリケーションでは、2 バイト文字が必要になることはありません。ただし、2 バイト言語をサポートする必要があり、データベース スキーマで 1 バイトしかサポートしていない場合、アプリケーション全体に戻って変更するのは非常にコストがかかります。
1 つのアプリケーションを varchar から nvarchar に移行するコストは、ほとんどのアプリケーションで使用するわずかな追加ディスク領域よりもはるかに高くなります。
一貫してください！VARCHAR を NVARCHAR に JOIN すると、パフォーマンスが大幅に低下します。
nvarchar は、メモリ、ストレージ、ワーキング セット、およびインデックス作成でかなりのオーバーヘッドが発生するため、実際には必要ないと仕様で規定されている場合でも、気にしないでください。
多くの状況で完全に無駄になる可能性があるため、厳密で高速な「常に nvarchar 」ルールはありません。特に、ASCII/EBCDIC からの ETL または識別子と、多くの場合キーと外部キーであるコード列です。
一方、列のケースはたくさんあります。この質問を早い段階で必ず行い、すぐに難しい答えが得られない場合は、列を nvarchar にします。
アプリケーションの場合、データベースのサイズが小さいため、nvarchar で問題ありません。「常に nvarchar を使用する」と言うのは、非常に単純化されすぎています。漢字やその他のクレイジーな文字などを保存する必要がない場合は、VARCHAR を使用すると、使用するスペースが大幅に少なくなります。私の現在の仕事の前任者は、必要のないときに NVARCHAR を使用して何かを設計しました。最近、それを VARCHAR に切り替えて、そのテーブルだけで 15 GB 節約しました (高度に書き込まれました)。さらに、そのテーブルにインデックスがあり、その列を含めたり、複合インデックスを作成したりする場合は、インデックス ファイルのサイズが大きくなります。
慎重に決定してください。SQLの開発とデータ定義では、「デフォルトの答え」はめったにないようです（もちろん、カーソルを絶対に避けることを除いて）。
アプリケーションが小さいため、varchar よりも nvarchar を使用してもコストが大幅に増加することは本質的になく、Unicode データを保存する必要がある場合に、後で頭を悩ませる可能性がなくなります。
一般的に言えば; 制約が最も少なく、最も高価なデータ型から始めます。生産に入れます。nvarcharパフォーマンスが問題になり始めた場合は、それらの列に実際に格納されているものを見つけてください。に収まらない文字はありvarcharますか？そうでない場合は、varchar に切り替えます。問題がどこにあるかを知る前に、事前に最適化しようとしないでください。私の推測では、 nvarchar/varchar のどちらを選択しても、近い将来にアプリケーションの速度が低下することはありません。アプリケーションの他の部分では、パフォーマンス チューニングによってより多くの費用対効果が得られます。
これについては経験から言えますが、注意してくださいnvarchar。どうしても必要な場合を除き、このデータ フィールド タイプは大規模なデータベースでのパフォーマンスを低下させます。パフォーマンスとスペースの点で問題のあるデータベースを継承しました。30GB のデータベースのサイズを 70% 削減することができました。パフォーマンスを向上させるために他にもいくつかの変更が加えられましたが、 がvarcharそれにも大きく貢献したと確信しています。データベースのテーブルが 100 万以上のレコードに成長する可能性がある場合は、絶対に近づかないでくださいnvarchar。
過去数年間、私たちのすべてのプロジェクトはすべて多言語であるため、すべてのプロジェクトで NVARCHAR を使用してきました。外部ソース (ASCII ファイルなど) からインポートされたデータは、データベースに挿入される前に Unicode にアップコンバートされます。
大きなインデックスなどによるパフォーマンス関連の問題はまだ発生していません。インデックスはより多くのメモリを使用しますが、メモリは安価です。
ストアド プロシージャを使用する場合でも、オンザフライで SQL を構築する場合でも、すべての文字列定数の前に N を付ける (例: SET @foo = N'Hello world.';) ようにすることで、定数も Unicode になります。これにより、実行時の文字列型変換が回避されます。
YMMV。
私は職場でよくこの質問に対処します。
在庫と価格の FTP フィード - varchar が正常に機能していた場合、アイテムの説明とその他のテキストは nvarchar でした。これらを varchar に変換すると、ファイル サイズがほぼ半分になり、アップロードが大幅に改善されました。
上記のシナリオは、誰かがアイテムの説明に特殊文字を入れるまでうまくいきました (おそらく商標、覚えていません)。
私はまだvarcharで毎回nvarcharを使用していません。特殊文字の疑いや可能性がある場合は、nvarchar を使用します。フィールドに何が入力されているかを100％制御しているときに、主にvarcharを使用していることに気づきました。
なぜ、これまでの議論の中で、UTF-8 について触れられていないのでしょうか? 文字の完全な Unicode スパンを格納できるからといって、1 文字あたり 2 バイト (または UNICODE 用語を使用する場合は「コード ポイント」) を常に割り当てる必要があるわけではありません。ASCII はすべて UTF-8 です。SQL Server は VARCHAR() フィールドをチェックして、テキストが厳密な ASCII (つまり、上位バイト ビット 0) であることを確認しますか? ないことを願っています。
次に、Unicode を保存し、古い ASCII のみのアプリケーションとの互換性が必要な場合は、 VARCHAR() と UTF-8 を使用することが魔法の弾丸になると思います。必要な場合にのみ、より多くのスペースを使用します。
UTF-8 に慣れていない方には、入門書をお勧めします。