2

私が取り組んでいるアプリケーションには、Oracle 11g dB で ADULT と CHILD の 2 つのテーブルが作成された従来の問題があります。これにより、ADULT と FK が適用されていない CHILD の両方のフィールドを持つ関連テーブルが多数作成されました。貧弱な開発が関係を間違ったフィールドにマッピングしたバグが発生しました。

テクニカル アーキテクトは、ADULT テーブルと CHILD テーブルを新しい ADULT_CHILD テーブルにマージし、テーブルの代わりにマテリアライズド ビューを作成することを計画しています。計画では、新しい id 値も作成し、関連するすべてのテーブルで I'd 値を置き換えて、plsql/apex コードが間違ったフィールドにマップされたとしても、データ マッピングは正しく行われるようにする予定です。

このソリューションの背後にある理由は、他のコードを変更する必要がないということです。

私の意見では、これはごまかしですが、私は Java/.NET OO に傾倒しています。

これは間違いであり、実際の解決策ではないことをアーキテクトに納得させるために、どのような議論を使用できますか? より複雑なソリューションを作成しているので、パフォーマンスが問題になるのではないかと心配しています。

ご指摘ありがとうございます

4

1 に答える 1

1

これは必要な解決策かもしれませんが、新しい問題を引き起こす可能性もあります。常に最新の MV を使用する必要がある場合は、コミットの更新が必要であり、その結果、すべての更新が順次行われる傾向があります。テーブルに書き込みを行うすべてのプロセスが、テーブルを更新するプロセスがコミットされるのを待機することを意味します。行ではなく、テーブルではありません。

そのため、現実的な負荷でアプローチをテストすることが賢明です。なぜ単一のテーブルにならなければならないのですか？FKを追加して、それらを分離したままにすることはできませんか? 更新をさらに制御する必要がある場合は、それらの名前を変更し、代わりにトリガーを使用してビューを配置します。

于 2012-11-13T21:50:58.533 に答える