データベースを設計するとき、nvarchar の大きさを決定する際にどのような決定を考慮しますか。
アドレス テーブルを作成する場合、古いアクセス データベースのように、アドレス ライン 1 が nvarchar(255) になるという直感的な反応になります。
これを使用すると、古い「文字列が切り捨てられる」という問題に悩まされることがわかりました。入力ボックスを制限することでこれを防ぐことができることはわかっていますが、ユーザーが実際に 255 を超えるアドレス行を持っている場合は、これを許可する必要があります。
nvarchar(????) をどのくらいの大きさにする必要がありますか?
私の推奨事項：本当に必要なだけ大きくしてください。
たとえば、郵便番号列の場合、10 ～ 20 文字で十分です。電話番号についても同様です。電子メールは 50 ～ 100 文字と長くなる場合があります。名前 - ええと、私は通常 50 文字で十分です。名についても同様です。本当に必要な場合は、いつでも簡単にフィールドを拡張できます。それは大したことではありません。
すべての varchar/nvarchar フィールドをできるだけ大きくしても意味がありません。結局、SQL Server ページは固定されており、1 行あたり 8060 バイトに制限されています。NVARCHAR(4000) の 10 個のフィールドを持つことは、単に問題を引き起こしているだけです.... (実際にそれらにあまりにも多くのデータを入力しようとすると、SQL Server があなたを怒らせます)。
非常に大きなフィールドが本当に必要な場合は、NVARCHAR/VARCHAR(MAX) を使用します。これらは、収まる限りページに格納され、大きくなりすぎると「オーバーフロー」ストレージに送信されます。
NVARCHAR 対 VARCHAR: これは、日本語、中国語、またはその他の非 ASCII スタイルの文字など、「特殊な」文字が本当に必要かということになります。ヨーロッパでは、一部の東ヨーロッパの文字でさえ VARCHAR フィールドで表すことができなくなりました (ハチェック (? スペル ?) が削除されます)。西ヨーロッパの言語 (英語、ドイツ語、フランス語など) はすべて、 VARCHAR。
しかし: NVARCHAR は常に、ディスク上と SQL Server メモリ内の 2 倍のスペースを使用します。本当に必要な場合は必要ですが、本当に必要ですか? ：-） それはあなた次第です。
マルク
個人的には nvarchar を使用しません :-) 私は常に varchar を使用します。
ただし、名前に 100、コメントに 1000 を使用する傾向があります。より長い文字列のトラップと処理は、たとえば正規表現を介してクライアントが実行できるため、SQL は期待するデータのみを取得します。
たとえば、ストアド プロシージャを介して呼び出しをパラメータ化することで、切り捨てエラーを回避できます。たとえば、パラメーターが varchar(200) として定義されている場合、200 を超える値を送信すると、切り捨てがサイレントに発生します。切り捨てエラーは、INSERT または UPDATE ステートメントに対してのみスローされます。パラメーターでは発生しません。
vachar が 255 に制限されていたため、SQL Server の 255 の「制限」は 6.5 に戻ります。SQL Server 7.0 + は 8000 に変更され、Unicode のサポートが追加されました。
編集：
nvarchar を使用しない理由: メモリ フットプリントが 2 倍、インデックス サイズが 2 倍、ディスク サイズが 2 倍、単に必要ないからです。私は世界中にオフィスを持つスイスの大企業で働いているので、偏狭ではありません。
ここでも説明: varchar と nvarchar のパフォーマンス
さらに考えてみると、クライアント開発者には Unicode をアピールすることをお勧めしますが、開発者 DBA として、私はパフォーマンスと効率性に重点を置いています...
フィールドが何を表しているかによって異なります。簡単なプロトタイプを作成する場合は、デフォルトの 255 のままにします。コメントなどの場合は、おそらく 1000 に設定します。
私が本当に小さくする唯一の方法は、郵便番号やNI番号などのサイズを確実に知っているものです.
名前、電子メール、住所など、特定の制約が必要な列の場合は、適度に長い最大長を設定する必要があります。たとえば、名前が 50 文字を超えると少し疑わしいと思われ、それを超えるサイズの入力には、名前だけでなくそれ以上の文字が含まれる可能性があります。しかし、データベースの初期設計では、妥当なサイズを 2 倍にします。したがって、名の場合は、100 (または 100 が「妥当なサイズ」である場合は 200) に設定します。次に、アプリを本番環境に置き、ユーザーがデータを収集するのに十分な時間遊んでから、実際のmax(len(FirstName)). そこに疑わしい値はありますか？50文字を超えるものはありますか? そこに何が入っているか調べて、それが実際にファーストネームかどうかを確認してください。そうでない場合、入力フォームにはおそらくより良い説明/検証が必要です。
コメントについても同じことを行います。nvharchar(max)初期値に設定します。次に、パフォーマンスの最適化を開始するのに十分なほどデータベースが大きくなったときに戻ってきます。コメントの最大長を 2 倍にすると、列の最大長が適切になります。