sql - 短いテキスト文字列を SQL Server データベースに格納するにはどうすればよいですか?

Question

varchar(255)、varchar(256)、nvarchar(255)、nvarchar(256)、nvarchar(max) など?

256 は、スペース効率の良い丸みを帯びた素敵な数のようです。しかし、私は 255 がよく使われているのを見てきました。なんで？

varchar と nvarchar の違いは何ですか?

Answer 1

MS SQL Server (7.0 以降) では、varchar データは最大 3 つの値で内部的に表されます。

• 0 から 8000 バイトを超える実際の文字列 (ページ サイズ、行に格納されている他の列、およびその他のいくつかの要因に基づきます)
• データ文字列の長さを示すために使用される 2 バイト (0 から 8000+ までの値を生成)
• 列がヌル可能である場合、行のヌル ビットマスクの 1 ビット (したがって、最大 8 つのヌル可能列のヌル ステータスを 1 バイトで表すことができます)

重要な部分は、2 バイトのデータ長インジケータです。1 バイトの場合、長さが 0 ～ 255 の文字列しか適切に記録できません。2 バイトの場合、長さが 0 から 64000 以上 (具体的には 2^16 -1) までの文字列を記録できます。ただし、SQL Server のページの長さは 8k であり、これが 8000 文字以上の制限の由来です。(SQL 2005 にはデータ オーバーフローの問題がありますが、文字列がそれほど長くなる場合は、varchar(max) を使用する必要があります。)

したがって、varchar データ型の列を (15, 127, 511) と宣言する長さに関係なく、各行に実際に格納されるのは次のとおりです。

• 文字列の長さを示す 2 バイト
• 実際の文字列、つまりその文字列の文字数

私の要点は次のとおりです。多くの古いシステムでは、文字列の長さを格納するために 1 バイトしか使用されていなかったため、最大長は 255 文字に制限されていましたが、これはそれほど長くはありませんでした。2 バイトの場合、そのような恣意的な制限はありません... したがって、(技術志向でないと推定される) ユーザーにとって意味のある数値を選択することをお勧めします。、私は 50、100、250、500、さらには 1000 が好きです。ベースが 8000 バイト以上のストレージであることを考えると、255 または 256 は 200 または 250 と同じくらい効率的ですが、エンド ユーザーに説明するときは効率が低下します。 .

これは、1 バイト データ (つまり、ansii、SQL _ Latin1*_*General_CP1 など) に適用されます。異なるアルファベットを使用して複数のコードページまたは言語のデータを保存する必要がある場合は、nvarchar データ型を使用する必要があります (これは同じように機能すると思いますが、文字数には 2 バイトですが、データの実際の文字ごとに 2 バイトが必要ですバイトのストレージ)。nvarchar で 8000 または 4000 を超える可能性のある文字列がある場合は、[n]varchar(max) データ型を使用する必要があります。

また、データの長さを追跡するためだけに余分なバイトでスペースを占有することが非常に重要である理由を知りたい場合は、http://www.joelonsoftware.com/articles/fog0000000319.htmlをチェックしてください。

フィリップ

Answer 2

VARCHAR(255)。255 文字のストレージすべてを使用するわけではなく、必要なストレージだけを使用します。これは 255 であり、256 ではありません。これは、255 とヌル ターミネータ (またはサイズ バイト) のスペースがあるためです。

「N」はユニコードです。非 ASCII 文字が予想される場合に使用します。

Answer 3

char/varchar および N バリエーションを定義する際に考慮すべき点が他にもいくつかあります。

まず、可変長文字列をデータベースに格納するにはオーバーヘッドが発生します。N/VARCHAR は文字列と長さの両方を格納し、短い文字列を N/CHAR に格納する場合と N/VARCHAR に格納する場合の違いは 10 未満ではないため、一般的な経験則として、長さが 10 文字未満の文字列には CHAR を使用します。文字列の長さのオーバーヘッドの価値があります。

次に、SQL サーバーのテーブルは 8KB ページに格納されるため、データ行の最大サイズは 8060 バイトです (残りの 192 バイトは SQL によるオーバーヘッドに使用されます)。そのため、SQL では VARCHAR(8000) および NVARCHAR(4000) の最大定義列が許可されます。これで、VARCHAR(MAX) と Unicode バージョンを使用できるようになりました。ただし、それに関連して余分なオーバーヘッドが発生する可能性があります。

私が間違っていなければ、SQL サーバーは行の残りの部分と同じページにデータを格納しようとしますが、VARCHAR(Max) 列にあまりにも多くのデータを入れようとすると、それはバイナリとして扱われ、別のページに保存します。

CHAR と VARCHAR のもう 1 つの大きな違いは、ページ分割に関係しています。SQL Server が 8 KB のページにデータを格納する場合、1 ページに格納されるデータ行の数に制限はありません。行がページに収まらないほど大きな値を持つ VARCHAR 列を UPDATE すると、サーバーはそのページを分割し、いくつかのレコードを移動します。データベースに使用可能なページがなく、データベースが自動拡張に設定されている場合、サーバーは最初にデータベースを拡張して空白ページを割り当て、次に空白ページをテーブルに割り当て、最後に 1 つのページを 2 つに分割します。

Answer 4

英語以外の言語をサポートする場合は、nvarchar を使用することをお勧めします。

HTML は、標準の ASCII 文字が含まれている限り問題ありません。主に多言語サポートのデータベースで nvarchar を使用しました。

Answer 5

1 バイトには8 ビットがあり、 1 バイトには最大 256 個の異なる値を格納できます。

0 1 2 3 4 5 ... 255

最初の数字は 0 なので、合計で256 個の数字になることに注意してください。

したがって、nvarchar(255) を使用すると、文字列の長さを格納するために 1 バイトが使用されますが、1だけ転倒して nvarchar(256) を使用すると、その余分な 1 項目のためにさらに 1バイトが無駄になります。 255 (数値 256 を格納するには 2 バイトが必要なため)。

これは SQL サーバーの実際の実装ではないかもしれませんが、これが 256 項目よりも 255 項目に制限する典型的な理由だと思います。

nvarcharは Unicode 用で、1 文字あたり 2 バイト以上を使用し、varchar
は1 バイトのみを使用する通常の ASCII テキスト用です。

Answer 6

IIRC、255 は、MySQL の varchar の最大サイズです。テキスト データ型に切り替える前、またはある時点で (実際には、現在は大きいと思います)。したがって、255 に維持すると、互換性が得られる可能性があります。ただし、行動する前にこれを調べる必要があります。

varchar と nvarchar は、ascii と unicode のようなものです。varchar は 1 文字あたり 1 バイトに制限されていますが、nvarchar は 2 バイトを使用できます。そのため、varchar(8000) を使用できますが、nvarchar(4000) しか使用できません。

Answer 7

varchar と nvarchar はどちらもコンテンツに合わせてサイズを自動調整しますが、列の型を宣言するときに定義する数は最大です。

Unicode は 2 バイトであるため、「nvarchar」の値は「varchar」の 2 倍のディスク/メモリ領域を占有しますが、列の型を宣言するときは、バイト数ではなく文字数を宣言します。

したがって、列の型を定義するときは、列が保持する必要がある最大文字数を決定し、それを varchar (または nvarchar) サイズとして持つ必要があります。

経験則としては、列が保持する必要がある文字列の最大長を見積もってから、約 10% 多い文字数のサポートを列に追加して、将来の予想外に長いデータの問題を回避することをお勧めします。

Answer 8

varchar(255) は、SQL Server 7.0 以前の最大長でもありました。