フィールドのデータではスペースは重要ではないと仮定して、テーブルからデータを挿入、更新、または選択するときにスペースを削除することをお勧めしますか?
データベースが異なればスペースの処理も異なると思います。そのため、その頭痛の種を避けるために、フィールドデータの先頭と末尾のスペースを禁止する必要があると思います。
どう思いますか?
フィールドのデータではスペースは重要ではないと仮定して、テーブルからデータを挿入、更新、または選択するときにスペースを削除することをお勧めしますか?
データベースが異なればスペースの処理も異なると思います。そのため、その頭痛の種を避けるために、フィールドデータの先頭と末尾のスペースを禁止する必要があると思います。
どう思いますか?
先頭と末尾のスペースが重要でない場合は、挿入または更新する前にそれらを削除します。その場合、選択に不要なスペースがないはずです。
これにはいくつかの利点があります。行に必要なスペースが少ないということは、データページに存在する可能性のある行が増える可能性があることを意味します。これにより、データの取得が高速化されます(取得が少なくなります)。また、SELECTのデータを常にトリミングしているわけではありません。(ここではDRY [繰り返しない]原則を使用します)
ほとんどのシナリオでそれは良い習慣だと思います。データに価値がなく、データを削除するコストが最小限であると自信を持って言える場合は、データを削除します。
良い習慣だと思います。ユーザーが余分なスペースを入力することによって最終的に引き起こされたバグを追跡するために、1 時間、1 日、または任意の時間を費やすことほど、魂を砕くものはほとんどありません。この余分なスペースによって、レポートが微妙に間違ったものになったり、プログラムのどこかで例外が発生したりする可能性があります。ログやエラー メッセージ内のすべての print ステートメントを括弧で囲まないと、そこにあることに気付かない可能性があります。データベースから取得したデータを使用する前にスペースを宗教的にトリミングしたとしても、データの将来のユーザーに好意を示し、データを挿入する前にトリミングしてください。
私はそれらをトリミングします (実際に空白データを使用していない限り)。これは簡単に行うことができ、コードで問題が発生した場合にスペースを見つけるのが特に難しいためです。
一般的なデータエンティティの場合、オーバーヘッドの価値はありません。余分な空白行がたくさんあると思う理由はありますか?もしそうなら、DBサイズを抑えるためにトリミングするのは良い考えかもしれませんが、そうでなければそうではありません。
末尾のスペースは、特に ANSI_NULLS の動作に関して特に問題があります。
たとえば、colname = '1' は true を返すことができ、colname like '1' は false を返します。
したがって、varchar 列の末尾のスペースがあいまいな場合は、特にそのようなデータには実際の情報がなく、SQL Server の動作があいまいになるため、切り捨てが最も望ましいと考えられます。
たとえば、この質問での議論を見てください。
SqlServer の select ステートメントが、一致する行と、一致して末尾にスペースがある行を選択するのはなぜですか?