13

テーブルにフィールド レベルの検証を追加したいと考えています。「account_number」という名前のフィールドがあり、このフィールドは常に「luhn」チェックに合格する必要があります。「luhn_verify」という機能が適切に動作しているように見えます (興味がある場合は、Google で検索してください)。ブール値を返します。私の質問は：

この検証とチェック制約のトリガーを使用する場合、PostgreSQL に大きなパフォーマンス上の利点はありますか。

追加情報：

  • PostgreSQL 9.1
  • テーブルには現在、挿入トリガーはありませんが、更新はあります。

免責事項:

これはおそらくすでに回答されているように感じますが、明確な回答が見つからないようです。その場合は、重複としてマークし、元の質問/回答を参照してください。

DBA ボードへのより良い質問かもしれません。

4

1 に答える 1

19

経験則はCHECK、可能な場合は制約を使用することです。

CHECK制約は、より速く、より単純で、移植性が高く、必要なコードが少なく、エラーが発生しにくいものです。たとえば、トリガーは他のトリガーによって簡単に回避できます。

ATRIGGERはもっと複雑です。より複雑な要件のために、必要な場合に使用します。

制約があなたCHECKのケースに対して制限的すぎるか、ダンプのリロードに問題を引き起こす場合は、NOT VALID修飾子を中間点として使用できます (Postgres 9.2+)。そして、オプションで、VALIDATEそれは後で。見る：

于 2013-08-23T21:09:29.217 に答える