延期タイミングは PostgreSQL の一意/主キー制約の適用にどのような影響を与えますか?

一意/主キー制約の延期: 延期タイミングの調査

PostgreSQL では、一意キー制約と主キー制約は延期可能かどうかのいずれかとして定義できます。延期可能。制約チェックを延期すると柔軟性が高まり、制約が適用される前にデータ変更を行うことができます。

適用タイミング

制約が遅延可能としてマークされている場合、その適用タイミングは次のようになります。初期設定 (IMMEDIATE または DEFERRED) と、SET CONSTRAINTS を使用したその後の変更。概要は次のとおりです。

• NOT DEFERRABLE: 各行操作後の制約チェック。
• IMMEDIATE で DEFERRABLE: 各行操作後の制約チェックステートメント。
• DEFERRABLE with DEFERRED (または INITIALLY DEFERRED): 各トランザクション後の制約チェック。

分析例

与えられたものを調べてみましょうquery:

UPDATE tbl SET id = t_old.id FROM tbl t_old WHERE (t.id, t_old.id) IN ((1,2), (2,1));

この UPDATE は複数の行に対して動作するため、一意の主キー制約に違反する可能性があります。ただし、制約が DEFERABLE INITIALLY IMMEDIATE として定義されているため、成功します。上記のルールによれば、これはステートメントの完了後に制約チェックが行われ、変更を適用できることを意味します。

CTE 動作

データ変更 CTE、例で見られるように、同様に動作します。 CTE 内での更新の順序は予測できませんが、CTE 全体が実行された後も制約チェックは適用されます。

複数の UPDATE ステートメント

複数の UPDATE ステートメントが実行された場合単一トランザクション内で実行される場合、制約チェックは SET CONSTRAINTS が使用されているかどうかによって異なります。 SET CONSTRAINTS を使用しないと、各ステートメントの後にチェックが行われるため、予想どおり一意の違反が発生する可能性があります。

一意/主キーの区別

一意であることに注意することが重要です。 PostgreSQL では主キー制約が特別な扱いを受けます。遅延不可能な一意/主キー制約は各コマンドの後にチェックされますが、PostgreSQL では、標準に準拠した動作を実現するために、INITIALLY IMMEDIATE を使用して遅延可能として定義することをお勧めします。

結論

遅延された一意/主キー制約の動作は、特定のシナリオでは予想と異なる場合がありますが、必ずしもそうであるとは限りません。バグです。制約チェックを延期すると、データ変更に柔軟性がもたらされます。パフォーマンスを最適化し、予期しないエラーを回避するには、制約チェックの適用タイミングを理解することが重要です。

以上が延期タイミングは PostgreSQL の一意/主キー制約の適用にどのような影響を与えますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。