合体を使用して潜在的にnull値を比較するクエリを使用しています。クエリの保守が難しくなるだけでなく、見苦しいので、これを避けたいと思います。これを想像してみてください:
where coalesce(tbl1.field,'~') <> Coalesce(tbl2.field,'~')
...where句で30回以上繰り返されている。ヘッキーいや。
EXISTSでこの不機嫌さを回避できると思っていたのですが、間違っていたことがわかりました。
最良の代替策は、NULLの代わりに列のデフォルトとして合体した値を物理データモデルに駆動することです。これには、ビジネスが現在NULLを受け入れて表すものが何であれ、データモデルでトークン値が置き換えられることをビジネスが受け入れて理解する必要があります。NULLのトリッキーな点は、メタデータと論理データモデルでNULLが何を表すかを正確に記述することです。純粋主義者の観点から、複数のことを意味することは許されるべきではありません。他の選択肢は、NULLを別の値(NULLまたはNULLではない)と比較できないという事実に対処するための回避策です。
COALESCEは、Teradata(およびその他のデータベース)ではインラインCASEステートメントのように扱われます。WHERE句に多数のCOALESCEステートメントがある場合の問題は、COALESCEでは3つ以上の比較が可能であるため、オプティマイザーが結果のカーディナリティを正確に推定できない可能性があることです。COALESCE(A.Col1, B.Col2, C.Col3, '~')
遭遇した最初の非NULL値を返します。
参照テーブルのドメインにNULL値がないディメンションである場合は、NULLを考慮から除外できます。つまり、NULLは有効な主キーではありません。ただし、オプティマイザでは、NULLSが。のレコードのみをスプールすることが許可されている条件がテーブルに挿入される可能性が高いことがわかりますA.Col1 IS NOT NULL
。したがって、データモデルで許可されているNULLに関連するオーバーヘッドがあります。
私は常にCASEステートメントを使用します。それははるかに明確です。NULLSはすべてを台無しにします。それらは必要だと思いますが、通常は排除できると思います。私たちのデータモデラーは、「友達は友達にNULLを使わせない。私はそれが好きだ。