86

私はデータベース設計に関しては少し古い学校なので、列で正しいデータサイズを使用することに完全に賛成です。しかし、友人のためにデータベースをレビューしているとき、私は彼varchar(max)がたくさん使っていることに気づきました。さて、私の当面の考えは、それを彼に投げ返し、彼にそれを変えるように言うことでした。しかし、それから私はそれについて考え、彼がそれを使用しない正当な理由を思い付くことができませんでした（あなたが疑問に思っているなら、彼はdbを生成するためにケースタイプのツールを使用していました）。

私は使用法のトピックを研究してきましたがvarchar(max)、彼がそれを使用しない理由を本当に思いつくことはできません。

彼はインデックスの列を使用していません。データベースにあるアプリケーションは入力に制限があるため、フィールドに大量のエントリを許可しません。

私が彼に光を見せてくれるのを手伝ってくれる助けをいただければ幸いです:)。

4

9 に答える 9

39

これに対する私の答えは、Maxの使用法ではなく、VARCHAR（max）とTEXTの理由に関するものです。

私の本では; まず第一に、英語のテキスト以外は決してエンコードせず、人々が外国の場所の名前を参照しないことが絶対に確実でない限り、NVARCHARまたはNTEXTを使用する必要があります。

第二に、それはフィールドがあなたにできることです。

TEXTは、VARCHARと比較して更新するのは難しいですが、フルテキストインデックスと多くの巧妙な機能を利用できます。

一方、VARCHAR（MAX）にはあいまいさがあり、セルのサイズが8000文字未満の場合、行データとして扱われます。それより大きい場合は、ストレージの目的でLOBとして扱われます。RBARにクエリを実行しないとこれを知ることができないため、データとその読み取りにかかるコストを確認する必要がある場所の最適化戦略がある可能性があります。

それ以外の場合、使用法が比較的平凡で、データのサイズに問題がないと予想される場合（つまり、.Netを使用しているため、string / char *オブジェクトのサイズを気にする必要はありません）その場合、VARCHAR（max）を使用しても問題ありません。

于 2011-08-21T21:58:30.327 に答える
15

ここにvarcharmaxを使用しない理由についてのブログ投稿があります

編集

基本的な違いは、データが保存される場所です。SQLデータ行の最大サイズは8000バイト（または8K）です。その場合、2GBのvarchar（max）をデータ行に格納できません。SQLServerはそれを「行外」に格納します。

したがって、データがディスク上の同じ場所にないため、パフォーマンスが低下する可能性があります。http：//msdn.microsoft.com/en-us/library/ms189087.aspxを参照してください。

于 2011-08-21T22:01:16.807 に答える
3

OLTP環境で作業している場合は、パフォーマンスがすべてです。オーバーヘッドとチューニングの懸念から、インデックス作成の制限とクエリのボトルネックまで。varcahr（max）または他のLOBタイプを使用すると、ほとんどの設計のベストプラクティスに違反する可能性が高いため、他のタイピングメカニズムを使用して処理できない特定のビジネスニーズがなく、varchar（max）のみが適合します。それでは、なぜシステムとアプリケーションをLOBデータ型の1つに固有のオーバーヘッドとパフォーマンスの問題にさらすのでしょうか。

一方、OLAP環境またはスタースキーマDW環境で作業していて、記述子フィールドが自然に冗長である必要があるディメンションテーブルがある場合は、インデックスに追加しない限り、varchar（max）を使用します。役に立つかもしれません。それでも、char（x）varchar（x）を使用することをお勧めします。これらのリソースのみを使用することが常にベストプラクティスであるため、作業を完了するために絶対に必要なものです。

于 2015-07-03T04:24:51.730 に答える
1

大量のデータが予想される場合を除いて、これらを使用しないでください。その理由は次のとおりです（Books Onlineから直接）。

ラージオブジェクト（LOB）データ型ntext、text、varchar（max）、nvarchar（max）、varbinary（max）、xml、またはimageの列は、索引のキー列として指定できません。

パフォーマンスを低下させたい場合は、すべてにnvarcharを使用してください。

于 2012-04-11T18:05:38.730 に答える
1

Redgateはこれについて素晴らしい記事を書きました。
https://www.red-gate.com/simple-talk/sql/database-administration/whats-the-point-of-using-varcharn-anymore/

結論

  • 必要に応じて、パフォーマンス上の利点がない場合でも設計が適切であり、VARCHAR（MAX）データが圧縮されないため、VARCHAR（MAX）ではなくVARCHAR（n）を使用します。
  • 大きな文字列の保存は、小さな文字列の保存よりも時間がかかります。
  • 行内のVARCHAR（MAX）値を8,000未満から8,000を超える値に更新するのは比較的遅くなりますが、単一のトランザクションの違いは測定できない可能性があります。
  • 行内のVARCHAR（MAX）値を8,000を超えて8,000未満に更新すると、テーブルが行外のデータを格納するように設定されている場合よりも高速になります。
  • VARCHAR（MAX）にout-of-rowオプションを使用すると、文字列が非常に長くなるまで書き込みが遅くなります。
于 2018-08-30T16:07:53.723 に答える
1

なぜだめですか？varchar（max）を使用しない理由は次のとおりです。

  1. 古き良きBLOBと同様に、SQL Serverはvarchar（max）列にインデックスを付けることができません。
  2. 行ごとに少なくとも8バイトを割り当てるため、特にvarchar（max）をオーバープロビジョニングするのは無駄であり、怠惰です。開発者がシングルバイトのバイナリ（True / False）変数に「max」を割り当てているのを見たことがありますが、後でこれらの値を使用してデータを識別するときにシステムが糖蜜のように遅いことがわかりました。
  3. そこに保存されているデータ型を推測することはできません。明らかなユースケースの例外は、最大8Kの実際の大きなテキストチャンクを保存することです。
于 2021-12-15T18:07:22.797 に答える
0

パフォーマンス、メモリ、ストレージの観点から、SQLサーバーが大きな（宣言された）varcharフィールドをどのように処理するかはわかりませんが、小さな宣言されたvarcharフィールドと同じくらい効率的に処理されると仮定すると、整合性制約の利点があります。

データベース上にあるアプリケーションには入力制限があるはずですが、アプリケーションにこの点でバグがある場合、データベースはエラーを適切に報告できます。

于 2011-08-21T21:58:08.703 に答える
0

差分は次のとおりです。インデックスを
VARCHAR(X)作成できます。インデックスを作成
VARCHAR(MAX)できません。

于 2013-10-31T15:09:00.343 に答える
0

   アプリケーションがデータベースに短い文字列のみを渡すと信じるのはやや古風であり、それで問題はありません。

   現代では、データベースは主に現在のアプリケーションによってアクセスされることを予期する必要がありますが、アプリケーションの将来のバージョンが存在する可能性があります（そのバージョンの開発者は文字列を特定の長さ未満に保つことを知っていますか？）

   データベースへのアクセスには、Webサービス、ETLプロセス、 LYNCからSQL、およびその他の多数の既存のテクノロジやまだ存在しないテクノロジが使用されることを予期する必要があります。

結局のところ、varchar（4000）は4000文字な   ので、一般的には、varchar（4000）を超えないようにしています。それを超える場合は、他のデータ型を調べて、保存しようとしているものをすべて保存します。 ブレントオザルはこれについてかなり素晴らしいものを書いています。

とはいえ、プロジェクトに取り組んでいるときは、現在の要件に対する現在の設計のアプローチを   評価することが重要です。さまざまな部分がどのように機能するかを理解し、さまざまなアプローチのトレードオフを理解し、目前の問題を解決します。いくつかの優れた公理を行使すると、盲目的なアドヒアランスにつながる可能性があり、レミングに変わる可能性があります。

于 2018-05-02T15:39:59.820 に答える