(小さい) 最大サイズを指定する代わりに、nvarchar(max) 型の列を定義することに不利な点があるかどうか疑問に思っています。
列の値が 4?KB を超える場合、残りのデータが「オーバーフロー」領域に追加されることをどこかで読みましたが、これで問題ありません。
ほとんどの場合、テキストが数行になるテーブルを作成していますが、下限を設定してから、その制限を破らないように検証を追加することに利点があるかどうか疑問に思っていました。
nvarchar(max) 列を使用したインデックスの作成に制限はありますか、またはサイズ制限に制限を追加するために支払うものはありますか?
ありがとう！
厳密に言えば、MAXタイプは常に非MAXタイプよりも少し遅くなります。varchar（max）とvarchar（N）のパフォーマンスの比較を参照してください。しかし、この違いは実際には決して目に見えません。IOによって駆動される全体的なパフォーマンスのノイズになるだけです。
あなたの主な関心事は、MAXと非MAXのパフォーマンスであってはなりません。この列に8000バイト以上を格納する必要がある可能性があるという質問に注意する必要がありますか？答えが「はい」の場合、「はい」の可能性が非常に低い場合でも、答えは明らかです。MAXタイプを使用すると、後でこの列をMAXタイプに変換する手間は、非MAXタイプのパフォーマンス上のわずかなメリットに値しません。 。
その他の懸念事項（その列にインデックスを付ける可能性、MAX列を持つテーブルのONLINEインデックス操作が利用できないこと）は、Denisの回答によってすでに対処されています。
ところで、オーバーフロー領域にデータが残っている4KBを超える列に関する情報は間違っています。正しい情報は、テーブルとインデックスの編成にあります。
ROW_OVERFLOW_DATAアロケーションユニット
テーブル（ヒープまたはクラスター化テーブル）、インデックス、またはインデックス付きビューで使用されるパーティションごとに、1つのROW_OVERFLOW_DATAアロケーションユニットがあります。このアロケーションユニットには、IN_ROW_DATAアロケーションユニット内の可変長列（varchar、nvarchar、varbinary、またはsql_variant）のデータ行が8KBの行サイズ制限を超えるまでゼロ（0）ページが含まれます。サイズ制限に達すると、SQL Serverは、最大幅の列をその行からROW_OVERFLOW_DATAアロケーションユニットのページに移動します。この行外データへの24バイトのポインターは、元のページに保持されます。
つまり、4KBを超える列ではなく、ページの空き領域に収まらない行であり、「残り」ではなく、列全体です。
900 バイトを超える列にはインデックスを作成できません。ラージ オブジェクト (LOB) データ型の列 ntext、text、varchar(max)nvarchar(max)、varbinary(max)、xml、または image は、インデックスのキー列として指定できません
ただし、使用できますincluded columns
text、ntext、および image を除くすべてのデータ型が許可されます。指定された非キー列のいずれかが varchar(max)、nvarchar(max)、または varbinary(max) データ型である場合、インデックスはオフライン (ONLINE = OFF) で作成または再構築する必要があります。