ストアドプロシージャに接続したWebページがあります。このSQLデータソースには、int型のストアドプロシージャに返すパラメータがあります。
ASP.NETはデフォルトでint32に設定したいようですが、数値は6を超えることはありません。ASP.NETのデフォルトをオーバーライドして16に設定しても問題ありませんか、それとも将来的に競合が発生しますか?
仕様:データベースフィールドの長さは4、精度は10です。これにより、答えに違いが生じる場合。
ストアドプロシージャに接続したWebページがあります。このSQLデータソースには、int型のストアドプロシージャに返すパラメータがあります。
ASP.NETはデフォルトでint32に設定したいようですが、数値は6を超えることはありません。ASP.NETのデフォルトをオーバーライドして16に設定しても問題ありませんか、それとも将来的に競合が発生しますか?
仕様:データベースフィールドの長さは4、精度は10です。これにより、答えに違いが生じる場合。
たとえば、強制的に 1 バイトにし、数値が 255 を超えると、キャスト エラーが発生するリスクがあります (例外がスローされます)。ただし、6 を超えることはないとわかっていれば、問題にはなりません。
それが私だったら、私はそれを通常の int として使用するだけです。バイトにすることで、数バイト以外のものが大幅に節約されるかどうかはわかりません。例外がスローされるリスクが高すぎるため、サイズを小さくするとすべてのメリットが失われます。
int32 に固執します。とにかく、それがvbの「整数」とSQLのINTです。
int/int32 の代わりに tinyint/byte または short/int16 を使用しても、パフォーマンスが大幅に向上することはありません。
実際、int32 を期待するオブジェクトに対して行わなければならない可能性のあるすべてのキャストによって引き起こされる将来の頭痛の種は、あなたを夢中にさせるでしょう。
DB フィールドの長さが 4 であると言う場合、それは 4 バイトを意味し、これは Int32 (4 バイト = 32 ビット) に相当します。そのため、列は int32 として返されます。
SQL Server にはさまざまな整数データ型があります。数値が 6 を超えないことが確実な場合は、データベース内の列を "tinyint" として宣言する必要があります。これは 1 バイトを使用し、0 から255. 次に、SQL データ ソースはそれを「バイト」データ型に変換する必要があります。これは目的に適しています。
CLR "byte" == SQL "tinyint" (1 バイト) CLR "Short" (または int16) == SQL "smallint" (2 バイト) CLR "int32" == SQL "int"
編集:何かをできるからといって、そうすべきだという意味ではありません-マイケル・ハーレンに同意します。これらのあまり一般的ではないデータ型を管理するという開発上の頭痛の種は、非常に高性能なものを扱っていない限り、得られるわずかなパフォーマンスの向上よりも重要です。ソフトウェア (この場合、なぜ ASP.NET を使用するのでしょうか?)
ASP 側で Int16 を使用しても、あまり節約できません。最終的には 32 ビット レジスタにロードする必要があります。
参考までに、CLR は int を Int32 に内部的にマップします。
SQL Serverストアド プロシージャで定義されているものを使用します。SQL Serverの場合int
は、.NET で Int32 を使用します。SQL の smallint はint16
.
それ以外の場合、SQL Server は自動的にアップコンバートするか、ダウンコンバートする必要がある場合はエラーをスローします。