1

簡単なメモ: クライアントの問題を解決するために 19 日間の猶予があります。

背景: クライアントは、新しいアプリを 3 か月で出荷できると豪語する請負業者を雇いました。2か月と数日後、私は連れてこられ、その人は手放されました。完全なコードはなく、スキーマに何も考えられておらず、UI の嫌悪感もありません。

私には 2 つのアプリケーションがあります。1 つは必要なすべてのデータを持ち、もう 1 つはそうではありません。私は新しい TDD スタイルのコードを書いており、データ自体以外のすべての問題をカバーする、部分的に不正な操作を行った SOA インフラストラクチャを目指しています。もっと時間があれば、liquibase を使用してスキーマを忌まわしき破片にリファクタリングできますが (想像力を働かせてください)、そうしません... したがって、プラン B は次のとおりです。

アプリ A (挿入|更新|削除) エンティティ Foo は AppASchema.FooTable を更新し、ポスト トリガーを介して AppBSchema.FooLikeTable を更新し、その逆も同様です。

これが非常識なアイデアであることはわかっていますが、これは私が持っている最悪のアイデアの中で最も小さいものです。私の懸念は

  1. 無限ループを作成する可能性があります ( AppA トリガーは AppA を更新する AppB を更新します)
  2. 高い負荷はありませんが、これは基本的に ops を n*2 に倍増させるため、MySQL サーバーの容量の半分に達すると、インデックスの更新などの基本的な処理のために事実上フル容量またはそれに近い容量になるようです。
  3. さまざまな祝福として、元のスキーマ設計者はすべてのテーブルを InnoDB エンジンにしました...これはパフォーマンスにとって恐ろしいことですが、このセットアップにより、整合性を維持する可能性が高くなります。

トリガーを実装するための私の時間予算は 12 時間またはバーストです。

4

1 に答える 1

1

AppASchema.FooTable と AppBSchema.FooLikeTable は十分に類似しており、そのうちの 1 つを更新可能なビューとして再実装できますか? アプリ スキーマの 1 つに固有の列を保持するために、いくつかの追加のテーブルを作成する必要がある場合があります。これは、一連のトリガーよりもはるかに保守しやすいでしょう。

そうでない場合、トリガーを使用して実装する必要がある場合は、再帰的なトリガーの依存関係がないことを確認するために非常に注意する必要があることは間違いありません。少数のテーブルがあり、それらがかなり類似している場合、これはそれほど難しくありません。表が多い場合や類似点が少ない場合は、時間がかかります。

于 2009-10-10T00:42:56.610 に答える