1

多くの製品/顧客/注文を含むデータベースがあり、コードベース (java/c#) にすべてのビジネス ロジックが含まれているとします。夜間には、データをフラット ファイルにエクスポートし、それらを独自のシステムに ftp するために、いくつかのバッチが必要です。

この「データベースをフラットファイルに書き込む」をどのように行うべきですか?ベストプラクティスは何ですか?

いくつかの考え：

  • ストアド プロシージャを作成し、f.ex ssis を使用してデータをフェッチできますか? 「バッチ出力データベーステーブル」がある場合はこれを行うことができますが、ファイルが書き込まれる前にロジックを実行する必要がある場合はそうではありませんか?

  • ドメインの残りの部分と同じリポジトリ/ビジネス ロジックを使用して、マネージド コードですべてのロジックを実行できますか? (これは、ストアド プロシージャ ソリューションに比べて処理が遅くなる可能性があります)

  • ドメイン サービスの唯一のインターフェイスが Web サービス (各要求に「長い」時間がかかる可能性がある) である場合、「ベスト プラクティス」は変更されますか?

4

2 に答える 2

2

個人的には、ストアド プロシージャの代わりに通常の (管理された) コードを使用してフィードを実装することを好みます。主な理由は次のとおりです。 3) 通常のビジネス ロジックに使用する同じコードを再利用できます (同じプロジェクトを参照するだけでも有益です)。 4) 多くの場合、他のシステムからの情報を使用してデータを強化する必要があります。これもマネージ コードから行う方がはるかに簡単です。5) マネージド コードのテスト、すべての単体テスト、自動ビルドなどのテストがはるかに簡単です。

ストアド プロシージャですべてを実行するよりもはるかに遅くする必要がある理由がわかりません。必要なデータを抽出するための優れたストアド プロシージャを作成するだけで、C#/Java アプリがすべての変換、強化などを行います。

編集: コメントへの回答: 既存のストアド プロシージャを再利用するか、微調整するか、新しいプロシージャを作成するかを言うことはできないと思います。ロジックの重複を避けるために、1 セットの proc を使用しようとするよりも、パフォーマンス ヒットまたは必要な変更が大きすぎないと思います。しかし、違いが大きい場合、追加の proc を維持するコストは、既存のものを変更してリリースするよりもおそらく低くなります。

于 2009-02-24T14:06:15.170 に答える
0

既に取得しているリポジトリ コードを使用します。いくつかのパフォーマンス テストを行い、パフォーマンスを満たしているかどうかを確認します。要件。重要なパフォーマンスがある場合。あまりにも多くの DB IO に突き止められる問題を解決するには、sproc を使用するか、バルク エクスポート リポジトリを実装します。

于 2009-02-27T07:41:31.387 に答える