EDIT : 双方向トリガーを使用した同期の詳細な説明; 構文、言語、および明確さの更新。
前文
私は 7 年間取り組んできた大規模な Web アプリケーションのデータ モデルのアップグレードで同様の問題に直面したので、あなたの痛みを感じています。この経験から、私は少し違うものを提案しますが、実装がはるかに簡単になることを願っています. しかし、最初に、観察：
組織にとっての価値はデータです。データは、現在のすべてのアプリケーションよりも長く存続します。ビジネスは、収集したデータから価値を引き出す新しい方法を絶えず発明し、新しいレポート、アプリケーション、およびビジネスの方法を生み出します。
したがって、新しいデータ構造を正しく取得することが最も重要な目標です。他の短期的な開発目標に対して、構造を正しくすることをトレードしないでください。特に:
- 新サービスの展開などの運用目標
- パフォーマンスを報告する (代わりに具体化されたビュー、トリガー、またはバッチ ジョブを使用してください)
この構造は時間の経過とともに変化するため、アーキテクチャは頻繁な追加とまれな正規化を可能にする必要があります。これは、データ構造とそれに対する共有 API (RESTful サービスを含む) が適切にバージョン管理されている必要があることを意味します。
なぜ RESTful Web サービスなのか?
「すべての機能をRESTfulサービスに移行して、アプリケーションがデータベースに直接アクセスできないようにする」と述べています。レガシー アプリに関して非常に重要な質問をする必要があります。なぜこれが重要で、どのような価値がもたらされたのでしょうか?
私が尋ねる理由：
- ACID トランザクションが失われます (恐ろしく複雑な WS-* 標準を実装しない限り、各呼び出しは単一のトランザクションです)。
- パフォーマンスの低下: データベースへの直接接続は高速になり (Web サーバーの作業や変換が不要)、遅延が少なくなり (通常は 50 ～ 100 ミリ秒ではなく 1 ミリ秒) 、直接 DB 接続用に作成されたアプリケーションの応答性が目に見えて低下します。
- データベース構造は RESTful サービスから抽象化されていません。データベースの正規化では、Web サービスを書き直し、それらを呼び出すアプリケーションを書き直す必要があることを認識しているためです。
その他の分野横断的な懸念事項は変更されていません。
- 管理性: ここにある多くの汎用ツールを使用して、データベースへの直接接続を監視および管理できます。
- セキュリティ: 直接接続は、開発者が作成する Web サービスよりも安全です。
- 承認: データベースのアクセス許可モデルは非常に高度で、必要に応じてきめ細かく設定されています
- スケーラビリティ: Web サービスは (唯一の?) 直接接続されたデータベース アプリケーションであるため、データベースと同じくらいしかスケーリングしません。
従来の RESTful API を維持することで、データベースを移行し、従来のアプリケーションを実行し続けることができます。しかし、「レガシー」RESTful サービスを導入せずにレガシー アプリを維持できるとしたらどうでしょう。
データベースのバージョン管理
おそらく、「レガシー」アプリケーションの大半は、SQL を使用してデータ テーブルに直接アクセスします。データベース ビューも多数ある場合があります。
データ移行の 1 つのアプローチは、新しいデータベース (新しいスキーマに新しい正規化された構造を持つ) が古い構造を従来のアプリケーション (通常は別のスキーマから) へのビューとして提示することです。
これは実際には非常に簡単に実装できますが、レポート機能と読み取り専用機能のみが解決されます。レガシー アプリケーションの DML はどうですか? DMLは次を使用して解決できます
- 単純な変換のための更新可能なビュー
- 更新可能なビューが不可能なストアド プロシージャの導入 (たとえば、"INSERT INTO EMP (col1, col2, col3) VALUES (?, ? ?)" ではなく "CALL insert_emp(?, ?, ?)")。
- トリガーと DB リンクを使用して新しいデータベースと同期する「レガシー」テーブルを用意します。
トリガーを使用して新しい形式のテーブルへの双方向同期を備えたレガシー形式のテーブルを持つことは、力ずくの解決策であり、比較的醜いです。
2 つの異なるスキーマ (またはデータベース) に同一のデータが存在することになり、同期コードにバグがあるとデータが同期しなくなる可能性があり、「2 つのマスター」の問題という古典的な問題が発生します。そのため、これは最後の手段として扱ってください。たとえば、次のような場合です。
- 基本構造が変更された (例えば、リレーションのカーディナリティの変更)、または
- 従来の形式への変換は複雑な関数です (たとえば、従来の列が新しい形式の列の値の 2 乗であり、「4」に設定されている場合、更新可能なビューは正しい値が +2 か -2 かを判断できません)。 .
データにそのような変更が必要な場合、コードとロジックのどこかで大幅な変更が行われます。互換レイヤーに実装するか (利点: レガシー コードを変更しない)、またはレガシー アプリを変更できます (利点: データ レイヤーはクリーンです)。これは、エンジニアリング チームによる技術的な決定です。
上記のアプローチを使用してレガシー構造の互換性データベースを作成すると、レガシー アプリケーションへの変更を最小限に抑えることができます (場合によっては、コードをまったく変更せずにレガシー アプリケーションを継続できます)。これにより、開発とテストのコストが大幅に削減され (ビジネスにとって正味の機能向上はありません)、ロールアウトのリスクが大幅に削減されます。
また、組織にとっての真の価値に集中することもできます。
- 新しいデータベース構造
- 新しい RESTful Web サービス
- 新しいアプリケーション (RESTful Web サービスを使用して構築される可能性があります)
Web サービスの良い点
上記を Web サービス、特に RESTful Web サービスに対する批判として読まないでください。Web アプリケーションの有効化や異種システム間の統合など、適切な理由で使用する場合、これは優れたアーキテクチャ ソリューションです。ただし、データ移行中にレガシー アプリを管理するための最適なソリューションではない可能性があります。