PolarDB:依存関係の追跡

概要

外部キーの制約、ビュー、トリガー、関数などを含む多くのテーブルを含む複雑なデータベース構造を作成すると、オブジェクト間の依存関係のネットが暗黙的に作成されます。 例えば、外部キー制約を有するテーブルは、それが参照するテーブルに依存する。

データベース構造全体の整合性を確保するため、PostgreSQLでは、他のオブジェクトが依存しているオブジェクトを削除できないようにしています。 に応じて注文テーブルを使用すると、次のようなエラーメッセージが表示されます。

ドロップテーブル制品;
エラー: 他のオブジェクトが依存しているため、テーブル製品をドロップできません
詳細: テーブルオーダーの制約orders_product_no_fkeyはテーブルプロダクトに依存します
ヒント: ドロップを使用... CASCADEも依存オブジェクトをドロップします。

エラーメッセージには便利なヒントが含まれています。すべての依存オブジェクトを個別に削除したくない場合は、次のように実行できます。

ドロップテーブル制品CASCADE;

すべての依存オブジェクトは、それらに依存するオブジェクトと同様に、再帰的に削除されます。 この場合、注文テーブルは削除されず、外部キー制約のみが削除されます。 外部キーの制約には何も依存しないため、そこで停止します。 (あなたがドロップをチェックしたい场合... CASCADEはCASCADEなしでDROPを実行し、DETAIL出力を読み取ります。

CASCADEを指定するほぼすべてのDROPコマンドinPostgreSQLsupport。 もちろん、可能な依存関係の性質は、オブジェクトのタイプによって変化する。 CASCADEの代わりにRESTRICTを記述して、デフォルトの動作を取得することもできます。

注意

SQL標準では、DROPコマンドでRESTRICTまたはCASCADEを指定する必要があります。 そのルールを実際に適用するデータベースシステムはありませんが、デフォルトの動作がRESTRICTかCASCADEかはシステムによって異なります。

DROPコマンドが複数のオブジェクトを一覧表示する場合、CASCADEは指定されたグループ以外に依存関係がある場合にのみ必要です。 たとえば、DROP TABLE tab1, tab2と言うとき、tab2からtab1を参照する外部キーの存在は、CASCADEが成功する必要があることを意味しません。

ボディが文字列リテラルとして定義されているユーザー定義の関数またはプロシージャの場合、PostgreSQLは、引数や結果の型など、関数の外部に表示されるプロパティに関連付けられた依存関係を追跡しますが、関数ボディを調べるだけで認識できる依存関係は追跡しません。 例として、この状況を考えてみましょう。

CREATE TYPE rainbow AS ENUM ('red' 、'orange' 、'yellow' 、
                                 'green' 、'blue' 、'purple');

CREATE TABLE my_colors (色の虹、メモテキスト);

CREATE FUNCTION get_color_note (rainbow) RETURNSテキストAS
      'SELECT note FROM my_colors WHERE color = $1'
      言語SQL; 

PostgreSQLは、get_color_note関数がrainbow型に依存することを認識します。型を削除すると、引数型が定義されなくなるため、関数を強制的に削除します。 ただし、PostgreSQLはget_color_noteをmy_colorsテーブルに依存するとは見なさないため、テーブルが削除されても関数を削除しません。 このアプローチには欠点がありますが、利点もあります。 テーブルが見つからない場合でも、関数は何らかの意味で有効ですが、実行するとエラーが発生します。同じ名前の新しいテーブルを作成すると、関数が再び機能するようになります。