SQL Server 2008でNVARCHARフィールドを特定のサイズではなくMAXに設定し、アプリケーションのロジックからの入力を制限するとどうなるのか疑問に思いました。また、これらは悪い設計慣行でしょうか？
7197 次
6 に答える
7
NVARCHAR（MAX）は、古いNTEXTデータ型よりも小さいデータでのパフォーマンスがはるかに優れていますが、一部の領域では常にNVARCHAR（n）の方が効率的です。
原則として、保存しているデータを最もよく表すデータ型を使用することが、ほとんどの場合、ベストプラクティスです。
于 2009-05-28T11:27:04.177 に答える
5
パフォーマンスには多くの影響があります。特に、汎用文字列パディングスカラーUDFでは、入力が40文字を超えることはありませんでしたが、出力がVARCHAR（MAX）として宣言されている場合にパフォーマンスに大きな違いがあることに気付きました。VARCHAR（50）に変更すると、大幅に改善されました。
于 2009-05-28T11:21:52.300 に答える
3
SQLがこの種のデータを格納する方法が原因で、有限数を超える文字を保持できないことがわかっている場合は、すべてのフィールドをNVARCHAR（MAX）に設定しないでください。ページに収まるほど小さいデータが格納されます。ページですが、大きくなりすぎるとページから移動され、個別に保存されます。
また、標準のVARCHARの2倍のスペースを占めるUnicodeデータを格納するため、NVARCHARが必要ですか？標準文字を使用することがわかっている場合は、代わりにVARCHARを使用してください。
スロー、あなたのアプリケーションの使用法を考えてください。サイズに理論上の制限がないアドレスフィールドがある場合、封筒にどのように印刷しますか？フロントエンドアプリケーションにロジックを実装すると言いますが、それでもデータベースに大きすぎるデータを許可するのはなぜですか？また、フロントエンドのロジックを壊すデータがデータベースに入るとどうなりますか？
于 2009-05-28T11:18:28.157 に答える
3
他のすべての回答を補足するために、データが他のソースから取得される可能性があるシナリオにも注意してください。たとえば、アプリケーションの外部からインポートされたテキストファイルなどです。これは、インポートルーチンで複製しない限り、アプリケーションロジックをバイパスする可能性があります。
于 2009-05-28T12:30:11.257 に答える
1
主な欠点は、NVARCHAR(MAX)プレーンインデックスでインデックスを作成できないことです。
NVARCHAR(MAX)また、型の変数と、これらの変数を解析する関数のパフォーマンスにいくつかの問題があります。
SQL Serverデータをそのまま保存および取得し、の側で解析したくない場合は、問題ありませんNVARCHAR(MAX)。
于 2009-05-28T11:24:16.867 に答える
0
制限を設定すると、最大長に対する検証の副作用があります
于 2009-05-28T11:36:46.810 に答える