私は最近、多くの DB リファクタリングを行っており、シノニムが非常に便利になりました。シノニムを最初に入れたとき、リファクタリング中は非常に一時的なものになると思っていました。今、私は、これらの類義語のいくつかを維持する正当な理由があるかもしれないと考えています.
誰もそれらを本格的な抽象化レイヤーとして使用しましたか?
パフォーマンスのコストは?
インデックスに関する問題はありますか?
ヒントまたはトリック?
初めての質問です、お手柔らかにお願いします。
ありがとう
私は最近、多くの DB リファクタリングを行っており、シノニムが非常に便利になりました。シノニムを最初に入れたとき、リファクタリング中は非常に一時的なものになると思っていました。今、私は、これらの類義語のいくつかを維持する正当な理由があるかもしれないと考えています.
誰もそれらを本格的な抽象化レイヤーとして使用しましたか?
パフォーマンスのコストは?
インデックスに関する問題はありますか?
ヒントまたはトリック?
初めての質問です、お手柔らかにお願いします。
ありがとう
シノニムは既存のデータベース オブジェクトの抽象化/代替名であるため、テーブルの場合、インデックスの動作は基になるオブジェクトの動作と同じです。つまり、実行プランが生成されると、テーブルの使用に関係なく同じプランが生成されます。名前または対応する同義語。
実は、インデックスを使用しているときに問題が発生しました....このサイトに関連する投稿を作成する方法があるかどうかはわかりませんが、シノニムとテーブル インデックスに関する問題へのリンクを次に示します。
はい、シノニムは抽象化レイヤーまたは間接レイヤーとして使用できます。たとえば、実行時まで実際のデータベース名がわからない外部データベースのオブジェクトにアクセスする必要がある場合などです。シノニム名でオブジェクトを参照するSQLを記述し、後でシノニムを動的に作成できます。
インデックスの問題はありません。シノニムがテーブルまたはインデックス付きビューを参照している場合、それらのオブジェクトに定義されているインデックスはすべて有効です。
パフォーマンスは、完全修飾名でオブジェクトを明示的に参照する場合と同じである必要があります。