ストアドプロシージャの一時テーブルのすべてのvarchar
フィールドにvarchar(255)
を使用することについて、妻の仕事で議論があります。基本的に、1つのキャンプは255を使用する必要があります。これは、定義が変更されても常に機能するためです。もう1つのキャンプは、潜在的なパフォーマンス向上のためにソーステーブルのサイズを維持する必要があります。
パフォーマンスキャンプは正しいですか?他の影響はありますか?彼らはSQL Serverを使用しています。
一時テーブルの使用方法によっては、データの切り捨ての問題が発生する可能性があります。
この例は少し工夫されていますが、私のポイントを示しています。例:
一時テーブルは、長さ59の新しいvarchar値を喜んで受け入れます。しかし、ユーザーテーブルは受け入れられませんでした。手順でこれを処理する方法によっては、切り捨てまたはエラーが発生する可能性があります。
これらの問題を文書化して説明しない限り、手順は予期しない方法で実行される可能性があります。
個人的には、この質問に対する答えが100%正しいとは思いません。それは本当にそれらの一時テーブルの使い方に依存します。
お役に立てれば
ストアドプロシージャの一時テーブルのすべての
varchar
フィールドにvarchar(255)
を使用します。
私は実際のフィールド長の使用に傾くでしょう。
最近、MySQL(SQL Serverも同様であると想定しています)の一時テーブルは、各varchar
列に可能な最大長を格納するのに十分なメモリを割り当てます...の200%〜500%を割り当てる体系的なアプローチすべてのストアドプロシージャのvarchar
フィールドに必要なメモリは、システムリソースの不要な描画のようです。これらの一時テーブルを作成するために大量のメモリを使用している場合、キャッシュに使用されていたメモリを不必要に要求し、ストアプロシージャが完了した後でも、将来のある時点でサーバーにより多くの作業を作成する可能性があります。
編集:ビルカーウィンの回答を参照してください: https://stackoverflow.com/questions/1962310/importance-of-varchar-length-in -mysql-table