Ergo: 現在 SQL Server データベースを設計する場合、常に NVARCHAR を使用する必要があります。
これは健全な推論ですか？誰かが前提のいずれかに同意しませんか? 現在、NVARCHAR ではなく VARCHAR を選択する理由はありますか?
列に格納されるデータとデータ型を一致させます。同様の議論により、数値と日付は数字の文字列として表すことができるため、すべてのデータを NVARCHAR 列に格納しない理由を説明できます。
列に格納されるデータの最適な一致が VARCHAR である場合は、それを使用します。
ポイント4 保管スペースが非常に安価なので問題ありません。
それは単なるストレージではなく、帯域幅 (CPU、メモリ、バックアップ、リカバリ、転送) です。節約する。
nvarchar を使用しない正当な理由がまだあると思います。
ただし、新しい開発ではおそらく nvarchar esp を使用する必要があります。64 ビット システムが標準になりつつあるためです。また、企業は (たとえ小さなものであっても) グローバル化することが一般的になっています。
多くの異なるタイプの列に対して NVARCHAR ではなく VARCHAR を選択する必要があり、選択は列ごとに行われます。
NVARCHAR が発生する追加のオーバーヘッドを必要としない典型的な列は次のとおりです。
ID タイプの列: ナンバー プレート、SSN、患者カルテの識別子など。
コード列: 国際通貨コード (USD、UKP など)、ISO 国コード (US、UK など)、言語コード (en-us など)、会計セグメント コードなど
郵便番号と郵便番号の列。
nvarchar の比較は varchar よりもコストがかかるため、完全に有効であり、実際には Unicode 機能を必要としない場所、つまり一部の内部 ID では好まれます。
そして、保管コストは依然として重要です。何十億もの行がある場合、それらの「小さな」違いはかなり急速に大きくなります。
他の人が指摘しているように、それはストレージのコストだけではありません。
列の長さは、1 ページあたりの行数に影響します。ページあたりの行が少ないということは、キャッシュに収まる行が少なくなることを意味し、パフォーマンスが低下します。MSSQL では、インデックスが作成された NVARCHAR 列がインデックス内のより多くのスペースを使用すると想定しています。つまり、ブロックあたりのインデックス エントリが少なくなるため、インデックス内のブロックが増え、インデックスをスキャン (または検索) する際のシークが増え、インデックス付きアクセスも遅くなります。
そのため、あらゆる面でパフォーマンスが低下します。本当に気にしないのであれば (または、もちろん、パフォーマンスを測定して満足している場合)、それで問題ありません。ただし、Unicode 文字を格納する必要がある場合は、もちろん NVARCHAR を使用してください。
データベース全体で NVARCHAR を使用することによって得られる保守性は、パフォーマンス コストを上回る可能性があります。
この種の質問には常に同じ答えがあります。盲目的に従うべき魔法のルールはありません。現代のプログラミング言語での GOTO の使用でさえ正当化できます:ループと関数をサポートする言語で「goto」を使用することは有利ですか? もしそうなら、なぜですか？
答えは、頭を使って特定の状況について考えることです。この特定のインスタンスでは、要件が変更されたことが判明した場合は、いつでもデータベースで varchar から nvarchar に変換できることに注意してください。
次の 2 つの理由から、nvarchar 列が varchar に変換されるのを見てきました。
アプリケーションは、4 GB のデータベース サイズ制限があるMSSQL Express Editionを使用しています。単一テナントの Web アプリケーションや組み込み DBMS を使用するアプリケーションのように、多数のデータベース デプロイメントがある場合、MSSQL Standard Edition への切り替えはコストがかかりすぎます。ここでは、安価な SQL2008 Web Edition が役立ちます。
nvarchar(4000) では不十分ですが、ntext 列は必要ありません。したがって、varchar(8000) に変換します。ただし、ほとんどの場合、nvarchar(max) に変換する必要があります。
ポイント3は無効です。1 つの国でのみ使用するように設計されたシステムは、Unicode について心配する必要はありません。使用されている一部の言語/製品は、Unicode をまったくサポートしていないか、部分的にしかサポートしていません。たとえば、TurboTaxは米国のみを対象としているため (フランス語を含むカナダ版でも LATIN-1 のままです)、Unicode を必要とせず、心配する必要もなく、おそらくサポートしていません (私は知りません)。するかどうかはわかりますが、たとえそうであったとしても、それは単なる例です)。
「今日のアプリケーションは、常に Unicode 互換であるべきです。」
次のように表現すると、おそらくより有効です。
「今日のアプリケーションは、Unicode を適切に処理するために特別なことを行う必要がなく、それをサポートするために既存のコードベースやアプリケーションの他の部分を特別に更新する必要がない場合、常に Unicode 互換である必要があります。」
私の学習は、デフォルトとして「NVARCHARを使用する」ことです...しかし、@CadeRouxには良い点があります.USナンバープレートのように、データがASCII以外のものを決して保持しないことが確実な場合、VARCHARはあなたを少し節約するかもしれません料金。
彼のよくできた声明の裏側は、名前 (人、通り、場所) または自然言語のテキスト (電子メール、チャット、記事、ブログ投稿、写真のキャプション) を持つものにはすべて「NVARCHAR を使用してください」であると言えます。そうしないと、"firstname" 列で "François" や "José" を正しくエンコードできず、テキスト列で "外国の" 発音記号を含むテキストを使用できなくなります。セントマーク「¢」、段落記号「¶」、箇条書き「•」。(これらはいずれもASCII 文字ではなく、VARCHAR フィールドに入力するための適切な標準的な方法がないためです。信じてください。怪我をすることになります。)
私が取り組んできたどのプロジェクトでも、NVARCHAR を使用したことで叱られたことは一度もありません。また、コードや DB スキーマを (特に稼働中の実稼働システムで) 作り直さなければならなくなった場合、再調整に費やされたコストは、50% 小さいディスクを購入することによる「節約」を簡単に上回ります。
この質問を本当に理解するには、ASCII、Unicode、および Unicode の典型的なエンコーディング (UCS-2 や UTF-8 など) を理解する必要があります。
ストレージはこれまでよりも安価になっていますが、それでも、特定のハード ドライブに 2 倍のデータを保存できるとしたら、それは魅力的ですよね?
また、キャッシュ用の RAM とソリッド ステート ドライブもありますが、どちらもハード ドライブよりもはるかに高価です。何百万もの行がある場合は、よりコンパクトなデータ形式を使用すると効果的です。
データベース サーバーで UTF-8 をエンコーディングとして使用する方法はありますか? これにより、大部分が ASCII ロード用の低ストレージの利点と、拡張が可能になるように Unicode の範囲内で何でも格納できる機能が得られます。
VARCHARSQL 型のエンコーディングとしても UTF-8 をサポートするようデータベース ベンダーに依頼します。他の DB サーバーがどのようにそれを行っているかはわかりませんが、少なくとも MySQL と PostgreSQLのVARCHARおよびフィールドで UTF-8 を使用できることは知っています。TEXT
とはいえ、UTF-16 でエンコードされたフィールドを使用しない唯一の理由は、UTF-16 入力で壊れるアプリケーションと対話する必要がある場合です。これは、ASCII または ISO-8815 テキスト エンコーディングを処理するように設計されたほとんどのレガシー アプリケーションであり、UTF-8 を処理する方が適切です。
私はこのテーマの専門家ではありません。しかし、UTF-8 を使用して小さなスペースと Unicode の組み合わせを取得できなかった理由は何ですか?
インデックス（インデックス？...別の議論）がデータよりも大きいデータベースを見てきました。インデックス内のストレージ要求 (varchar) の半分で済む場合、特定のページのヒット密度が 2 倍になり、フィルファクタリングがより効率的になり、データの取得/書き込み/ロックが高速になり、ストレージ要件が少なくなると想定されます (すでに述べた）。