6

現在、Data-Access オブジェクトと、約 20,000 行のコードに相当する多くのストアド プロシージャとトリガーで手作業で作成された SQL を使用しています。単純な変更により、修正に数日かかる作業が発生し、締め切りが遅れる原因となっていることがわかっています。

変更には、追加データに対処するためのテーブルの変更、QA/ユーザー レポートに基づくスキーマの一般的なリファクタリングなどが含まれます。古くて遅いものを置き換えるために構築されている非常にアクティブなシステムです。

これらの変更の影響を制限するために利用可能な PHP ORM ソリューションを調べましたが、遅すぎてスキーマに対処できませんでした。「単純な」SQL の結果は、カスタム クエリよりも桁違いに長い時間がかかっており、約 0.5 秒のページ ビューが 20 秒以上かかっていました。

一般的なコンテキストで、リレーショナル データベースを使用したスキーマの進化に対処するために検討できるベスト プラクティス/戦略は何ですか?

編集：トリガーについて言及するのを忘れました。カスケード変更に依存する多くのデータがあります。ここでこのユーザーの価格を変更すると、そのユーザーの価格が更新されます。

4

5 に答える 5

3

Refactoring Databases: Evolutionary Database Designに関するこの本をチェックアウトすることをお勧めします。

于 2008-11-21T16:38:31.943 に答える
2

継続的 (または少なくとも毎晩) のビルド戦略を使用することをお勧めします。
チェックインのたびに、または少なくとも 1 日に 1 回、データベースを再構築します。
また、1 日 1 回、単体テストを実行して、ストアド プロシージャ、トリガー、データ アクセス レイヤーなど、コードの各ビットを実行します。

ストアド プロシージャを記述するには多大なコストがかかりますが、これによりブレークがすぐに特定されます。
壊れている場所がわかれば、それを修正できます。

この戦略をデータベースの変更に適用した他の人の経験を聞きたいです。

于 2008-11-20T16:39:42.267 に答える
2

DB 定義にはEnterprise Architectを使用します。UML で定義されたストアド プロシージャ、トリガー、およびすべてのテーブル定義が含まれます。プログラムの 3 つの優れた機能は次のとおりです。

  1. ODBC 接続から UML ダイアグラムをインポートします。
  2. DB全体のSQLスクリプト(DDL)を一度に生成
  3. DB のカスタム テンプレート ドキュメントを生成します。

開発者としての 10 年以上の経験の中で、他のツールにこれほど感銘を受けたことはありません。EA は、Oracle、MySQL、SQL Server (複数のバージョン)、PostGreSQL、Interbase、DB2、および Access を一挙にサポートします。問題が発生したときはいつでも、彼らのフォーラムが私の問題に迅速に答えてくれました。強くお勧めします！！

DB の変更が入ると、EA で変更を加え、SQL を生成し、バージョン管理 (svn) にチェックインします。構築にはHudsonを使用しており、チェックインされた sql を変更したことがわかると、スクリプトからデータベースを自動構築します。

于 2008-11-21T14:17:17.437 に答える
1

私のアドバイスは、ストアド プロシージャを取り除き、代わりにインライン SQL を使用することです。おそらく、テキスト/xml ファイルで管理されます。私は、SProcs の方がはるかに煩わしく、維持するのに時間がかかることがわかりました。クエリ プランが生成されると (クエリが初めて実行されるとき)、パフォーマンスの違いはほとんどありません。さらに、DB スクリプト全体をバージョン管理できるようになります...

于 2008-11-20T10:09:10.310 に答える
0

ここに私の提案があります：

  1. 最も使用頻度の低い機能を取り除くようにしてください。常に使用されていない機能について質問します。アプリケーションの各機能には、いくつかのレベルのコストが関連付けられています (保守、サポート、回帰テスト、コードの複雑さなど)。
  2. コード内で効率的かつスケーラブルな方法でストアド プロシージャを実行する方法がまったくない場合を除き、ストアド プロシージャには近づかないでください。
  3. ORM ソリューションを徐々に導入して (リファクタリングを使用して JDBC から ORM に移行)、コードの量と CRUD 操作のコードの複雑さを軽減します。
  4. バグを修正し、それらのテストを継続的インテグレーション システムに組み込むときに、機能テスト、統合テスト、単体テストをビルドします。チェックインによって問題が発生したらすぐに問題を特定するために、回帰テストを可能な限り自動化します。
  5. 一般に、バグを修正するたびに、その機会を利用してリファクタリングを行い、実装/コード モジュールを分離します。

データベースの移行の問題について質問がある場合は、http ://shashivelur.com/blog/2008/07/hibernate-db-migration/ が役立ちます。

于 2008-12-08T04:45:05.463 に答える