60列のテーブルがあります。そのうちの 20 個は「NotEmpty」で、6 個は「NotNull」です。
空の値と Null 値があります (私の場合は常に「データなし」を意味します)。1 種類の制約のみで列を統一したいと考えています。
null 値が安い (バイトサイズ) ことを読みました。それでは、NotEmpty 制約を使用しますか? しかし、NotNull 制約のほうがパフォーマンスが良いのではないでしょうか? それともcoalesce()、データを取得するときに値と使用の両方を使用する方がよいでしょうか?
Postgres 9.xのCHECK制約INSERTのコストはいくらですか? UPDATEあなたの経験はどうですか？ベンチマークはありますか？
NULL一部の人々は、論理が混乱を招くと主張して、値を避けようとします。
私はその一人ではありません。NULL値は、データのない列には問題ありません。それらは確かに「空の」列を保存する最も安価な方法です - ディスク容量とパフォーマンスの点で (主な効果は小さなテーブルとインデックスです):
価値の性質を理解したらNULL、それを避ける理由はありません。Postgres には、NULL を処理するためのさまざまな関数が用意されています。colaesce()、nullif()、concat()、concat_ws()、 ...
一般に、パフォーマンスに関する限り、NOT NULL 制約はCHECK 制約よりも優れており、ログ ショットによる両方のトリガーよりも優れています。しかし、単純なトリガーでさえ安価です。NOT NULL制約のコストはほとんどありません。また、これらはすべて書き込み操作にのみ影響しますが、ほとんどのアプリケーションでは読み取り操作が支配的です。
したがって、パフォーマンスへの最も重要な影響 (準最適なインデックスとクエリは別として) は、テーブルとインデックスのサイズ、またはさらに重要なこととして、データ ページあたりのタプルの数です。タプルが大きくなると、ほとんどのユース ケースでパフォーマンスが低下します。それに応じて、クエリを満たすために読み取る必要のあるデータ ページの数が増加します。使用可能なキャッシュ メモリが早く飽和します。
ベンチマークの準備はできていませんが、特定の環境でテストすることをお勧めします。これらは単純な経験則です。現実はもっと複雑です。