3

いくつかの既存のテーブルをクラスターに結合することが決定されました。

これは明らかに、テーブルをクラスター化できるようにテーブルを再作成する必要があることを意味しますが、既存のデータは保持する必要があります。

当然、手順は次のようなものになると思います。

  • 別の名前で既存のテーブルをバックアップします(名前の変更などを介して)
  • 古い名前で新しいクラスター化されたテーブルを作成します
  • バックアップ テーブルのすべてのデータを新しく作成したテーブルにコピーします。

ただし、現在のテーブルにはかなりの数のトリガーが割り当てられています (ここで間違っている場合は修正してください)。そのテーブルで名前変更操作を実行すると、便宜上割り当てられたすべてのトリガーが自分自身をリファクタリングすると仮定します。新しい名前に合わせます。

この場合の完璧なシナリオは、名前が変更されたときにトリガーが一時的にテーブルから自分自身を「切り離し」(その時点では存在しない古いテーブル名を指している)、その後再び機能するようにすることです。新しく作成されたクラスター化されたテーブルが表示されます。

ただし、これが可能かどうかはわかりません。

ここでの質問は次のとおりです。テーブルの名前を変更するときにトリガーを残すことはできますか、それとも手動で処理する必要がありますか?

4

2 に答える 2

3

トリガーはテーブルを名前で参照せず、それらを作成する DDL のみが参照します。それらはテーブルの内部識別子を参照するため、テーブルの名前を変更してもトリガーはまったく変更されません。ただし、データベースからトリガーの DDL をリバース エンジニアリングすると、コードはもちろんテーブルの新しい名前を参照します。テーブル名を明示的に参照する場合、トリガー内のコードは変更されませんが、そうでないことを願っています。

もちろん、トリガーをテーブルから切り離すことはできません。トリガー、インデックス権限などの DDL をエクスポートするのが最善です。

同様に、インデックスはテーブル名を直接参照しません。

ここでの根本的な問題は、コード リポジトリを使用していないことです。これにより、テーブルの名前を変更し、関連するスキーマ アイテムを削除した後、特権の付与、インデックスの作成、トリガーの適用などに必要なスクリプトを再実行できるようになるためです。

于 2013-11-28T11:51:55.757 に答える