1562

nvarcharマルチバイト文字をサポートしているだけですか?その場合、ストレージの問題以外に、を使用する意味はありますvarcharsか?

4

20 に答える 20

1938

列には、任意nvarcharの Unicode データを格納できます。varchar列は 8 ビットのコードページに制限されています。varcharスペースを取らないので、それを使用すべきだと考える人もいます。これは正しい答えではないと思います。コードページの非互換性は苦痛であり、Unicode はコードページの問題を解決します。最近では安価なディスクとメモリが使用されているため、コード ページをいじくり回して時間を無駄にする理由はもうありません。

最新のオペレーティング システムと開発プラットフォームはすべて、内部で Unicode を使用しています。nvarcharではなくを使用varcharすることで、データベースからの読み取りまたはデータベースへの書き込みのたびにエンコード変換を行うことを回避できます。変換には時間がかかり、エラーが発生しやすくなります。また、変換エラーからの回復は重要な問題です。

ASCII のみを使用するアプリケーションとやり取りしている場合でも、データベースで Unicode を使用することをお勧めします。OS とデータベースの照合アルゴリズムは、Unicode でより適切に機能します。Unicode は、他のシステムとインターフェースするときの変換の問題を回避します。そして、あなたは将来に備えます。また、完全な Unicode ストレージの利点を享受している場合でも、維持する必要のあるレガシー システムのデータが 7 ビット ASCII に制限されていることを常に検証できます。

于 2008-09-29T02:16:22.780 に答える
292

varchar : 可変長の非 Unicode 文字データ。データベース照合は、データがどのコード ページを使用して格納されているかを決定します。

nvarchar : 可変長の Unicode 文字データ。比較のためのデータベース照合に依存します。

この知識を武器に、入力データに一致するもの (ASCII 対 Unicode) を使用します。

于 2008-09-27T19:37:02.390 に答える
76

私は常に nvarchar を使用しています。これにより、構築しているものは何でも、投げかけたほとんどすべてのデータに耐えることができます。nvarchar を使用したため、私の CMS システムは誤って中国語を実行します。最近では、新しいアプリケーションは、必要なスペースの量を気にする必要はありません。

于 2008-09-27T19:37:21.250 に答える
35

Oracle のインストール方法によって異なります。インストール プロセス中に、NLS_CHARACTERSET オプションが設定されます。クエリで検索できる場合がありますSELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET'

NLS_CHARACTERSET が UTF8 のような Unicode エンコーディングである場合は、すばらしいことです。VARCHAR と NVARCHAR の使用はほとんど同じです。今すぐ読むのをやめてください。それ以外の場合、または Oracle 文字セットを制御できない場合は、読み進めてください。

VARCHAR — データは NLS_CHARACTERSET エンコーディングで格納されます。同じサーバーに他のデータベース インスタンスがある場合は、それらによって制限される場合があります。設定を共有する必要があるため、その逆も同様です。このようなフィールドには、その文字セットを使用してエンコードできる任意のデータを格納できます。たとえば、文字セットが MS-1252 の場合、英字、いくつかのアクセント付き文字、およびその他のいくつか (€ や — など) などの文字のみを保存できます。あなたのアプリケーションは、世界の他の場所では動作できず、いくつかのロケールでのみ役に立ちます。このため、それは悪い考えと見なされます。

NVARCHAR — データは Unicode エンコーディングで保存されます。すべての言語がサポートされています。良いアイデアです。

収納スペースはどうする?VARCHAR は、文字セット/エンコーディングが特定のロケール用にカスタム設計されているため、一般的に効率的です。NVARCHAR フィールドは、皮肉なことに NLS 設定に基づいて、UTF-8 または UTF-16 エンコーディングで保存されます。UTF-8 は、アジア言語をサポートしながら、「西洋」言語に対して非常に効率的です。UTF-16 は、「西洋」言語をサポートしながら、アジア言語に対して非常に効率的です。ストレージ容量が心配な場合は、Oracle が必要に応じて UTF-8 または UTF-16 を使用するように NLS 設定を選択してください。

処理速度はどうですか?ほとんどの新しいコーディング プラットフォームはネイティブで Unicode を使用します (Java、.NET、さらには何年も前の C++ std::wstring です!) ため、データベース フィールドが VARCHAR の場合、Oracle は読み取りまたは書き込みのたびに文字セットを変換する必要があり、あまり良くありません。NVARCHAR を使用すると、変換が回避されます。

結論: NVARCHAR を使用してください。制限や依存関係を回避し、ストレージ スペースに適し、通常はパフォーマンスにも最適です。

于 2010-10-07T18:08:57.417 に答える
28

nvarchar はデータを Unicode として格納するため、多言語データ (複数の言語) をデータ列に格納する場合は、N バリアントが必要です。

于 2008-09-27T19:36:41.127 に答える
20

私の2セント

  1. 正しいデータ型を使用しないと、インデックスが失敗する可能性があり
    ます。 SQL Server の場合: VARCHAR 列にインデックスを作成し、それを Unicode 文字列で表すと、SQL Server はインデックスを使用しません。BigInt を SmallInt を含むインデックス付き列に提示すると、同じことが起こります。BigInt が SmallInt になるほど小さい場合でも、SQL Server はインデックスを使用できません。他の方法では、この問題は発生しません (SmallInt または Ansi-Code をインデックス付きの BigInt または NVARCHAR 列に提供する場合)。

  2. データ型は DBMS (DataBase Management System) によって異なる場合があります。
    すべてのデータベースのデータ型はわずかに異なり、VARCHAR はどこでも同じというわけではありません。SQL Server には VARCHAR と NVARCHAR がありますが、Apache/Derby データベースには VARCHAR しかなく、VARCHAR は Unicode です。

于 2013-04-19T09:53:33.663 に答える
18

にnvarcharはUnicode文字を格納し、varcharは非Unicode文字を格納します。

「Unicode」とは、アラビア語、ヘブライ語、中国語、日本語など、他の多くの言語の文字を1つの文字セットにエンコードできる16ビットの文字エンコード方式を意味します。

つまり、Unicodeは1文字あたり2バイトを使用して保存し、nonunicodeは1文字あたり1バイトのみを使用して保存します。つまり、Unicodeは、非Unicodeと比較して、保存するために2倍の容量が必要です。

于 2011-12-14T12:09:00.200 に答える
12

あなたが正しい。nvarcharUnicode データをvarchar格納し、シングルバイト文字データを格納します。すでに述べたストレージの違い(nvarcharの2倍のストレージスペースが必要)以外に、優先するvarchar主な理由は国際化(つまり、他の言語で文字列を保存する)です。nvarcharvarchar

于 2008-09-27T19:42:47.493 に答える
10

nVarchar は、Unicode 文字を格納するのに役立ちます。ローカライズされたデータを保存する場合は、これが最適です。

于 2008-09-27T19:36:09.847 に答える
10

私は言うでしょう、それは依存します。

OS が (現在のすべての Windows システムと同様に) Unicode で動作し、言語が Unicode をネイティブにサポートするデスクトップ アプリケーションを開発する場合 (Java や C# のように、デフォルトの文字列は Unicode です)、nvarchar を使用します。

文字列が UTF-8 として入力され、言語が PHP である Web アプリケーションを開発する場合、まだ Unicode を (バージョン 5.x で) ネイティブにサポートしていない場合は、おそらく varchar の方が適しています。

于 2010-01-25T10:19:26.503 に答える
8

文字を格納するために 1 バイトを使用する場合、256 の可能な組み合わせがあり、したがって 256 の異なる文字を保存できます。照合は、文字と、文字を比較およびソートするための規則を定義するパターンです。

Latin1 (ANSI) である 1252 が最も一般的です。シングルバイト文字セットも、多くの言語で使用されるすべての文字を格納するには不十分です。たとえば、一部のアジア言語には数千の文字があるため、1 文字あたり 2 バイトを使用する必要があります。

ユニコード規格

複数のコード ページを使用するシステムがネットワークで使用されると、通信の管理が難しくなります。物事を標準化するために、ISO および Unicode コンソーシアムはUnicodeを導入しました。Unicode は、各文字を格納するために 2 バイトを使用します。つまり、65,536 の異なる文字を定義できるので、ほぼすべての文字を Unicode でカバーできます。2 台のコンピューターが Unicode を使用する場合、すべての記号は同じ方法で表現され、変換は必要ありません。これが Unicode の背後にある考え方です。

SQL Server には、文字データ型の 2 つのカテゴリがあります。

  • 非 Unicode (char、varchar、および text)
  • Unicode (nchar、nvarchar、および ntext)

複数の国からの文字データを保存する必要がある場合は、常に Unicode を使用してください。

于 2014-06-04T13:29:55.103 に答える
6

私はここで言わなければなりません(私はおそらく自分自身をスレートに開放しようとしていることを認識しています!), 確かに、NVARCHARすべて照合がすべて従属システムとデータベース自体は同じです...? そうでない場合は、とにかく照合変換が発生する必要があるため、 と同じように実行可能になります。VARCHARVARCHARNVARCHAR

これに加えて、SQL Server (2012 年より前)などの一部のデータベース システムのページ サイズは約 100 です。8K。TEXTそのため、またはNTEXTフィールドのようなものに保持されていない検索可能なデータを格納することを検討している場合VARCHARは、8k 相当のスペースNVARCHARを提供しますが、4k (バイトを 2 倍、スペースを 2 倍) しか提供しません。

要約すると、どちらの使用も次のものに依存していると思います。

  • プロジェクトまたはコンテキスト
  • インフラストラクチャー
  • データベースシステム
于 2013-11-20T11:06:37.920 に答える