私は、おそらく最も自然にデータベース テーブルの計算のバッチとして記述され、月に 1 回実行されるプログラムの作業を開始しています。すべての入力は Oracle データベース テーブルにあり、すべての出力は Oracle データベース テーブルになります。このプログラムは、今後何年にもわたって保守可能である必要があります。
これを一連のストアド プロシージャとして実装し、それぞれが賢明な変換を実行することは簡単に思えます。たとえば、いくつかのビジネス ルールに従って部門間でコストを分配します。その後、単体テストを作成して、各変換の出力が期待どおりかどうかを確認できます。
これをすべてPL/SQLで行うのは悪い考えですか? C# などの典型的なオブジェクト指向プログラミング言語で大量のバッチ計算を実行しますか? PL/SQL などのデータベース中心のプログラミング言語を使用する方が表現力が豊かではないでしょうか?
次の要件を説明します
a）バッチ処理を実装できる必要がありますb）結果が維持可能である必要があります
私の反応：
上記のように、実装は、利用可能なスキル、適切な設計、および高品質のプロセスの順守に依存します。
効率的にするには、実装でデータをバッチで処理する必要があります（バッチで選択し、バッチで挿入/更新します）。オブジェクト指向アプローチの危険性は、データを行ごとに処理する設計に簡単に導かれることです。このタイプのアプローチには不要なオーバーヘッドが含まれており、行のバッチでデータを処理する設計よりも大幅に効率が低下します。
両方のアプローチをうまく使用することが可能です。
マシューバトラー
他のコメント投稿者が注意すべき点-問題はSQLではなくPL/SQLに関するものです。答えのいくつかは明らかにSQLに関するものであり、PL/SQLに関するものではありません。PL / SQLは完全に機能するデータベース言語であり、成熟しています。いくつかの欠点がありますが、ポスターがやりたいことのタイプについては、それは非常に良いです。
いいえ、必ずしも悪い考えではありません。解決策が簡単で、各プロセスをテストおよび検証できる場合、それは良い考えのように思えます。オブジェクトの作成とオーバーヘッドによりパフォーマンスが低下する可能性があるため、OO プラットフォームは (そうである必要はありませんが) 大規模なデータ セットには適していません。
オラクルは、あなたのような問題を念頭に置いて PL/SQL を設計しました。データベースと PL/SQL に関する十分な企業知識があれば、これは合理的な解決策のように思えます。PL/SQLから実際のSQLエンジンへの各コールはコンテキスト・スイッチであるため、大規模なバッチ・セットに注意してください。パフォーマンスを向上させるために、可能な場合は単一レコードのプロセスをまとめてバッチ処理する必要があります。
PL/SQL は、SQL とうまく統合できる成熟した言語です。Oracle の各バージョンでは、ますます強力になっています。また、Oracle 11 以降、PL/SQL はデフォルトでマシン コードにコンパイルされます。
作業中に何が起こっているのかを何らかの形で記録してください。そうしないと、ブラック ボックスができてしまい、どこかで何時間も動かなくなった場合、停止するか、「もう少し」動作させるかを迷ってしまいます。
通常、私はPL/SQLをできるだけ少なくすると言います.PL/SQLは通常、保守性がはるかに低くなります.最近の仕事の1つで、PL/SQLを扱うのがいかに面倒で難しいかを実際に見ました。
ただし、これはバッチ処理であり、入力と出力の両方が DB であるため、「可動部分」を最小限に抑えるために、ロジックを PL/SQL に入れることは理にかなっています。ただし、それがビジネスロジック、またはシステムの他の部分で使用されるコンポーネントである場合は、そうしないでください..
1 つのプロジェクトで、大量のバッチ処理プログラムとレポート生成プログラムを PL/SQL と Pro C の両方で作成しました。彼らは一般的に、私がPL/SQLで書くことを好んでいました。将来保守する彼ら自身の開発者は、Pro CコードよりもPL/SQLの方が理解しやすいと感じたからです。
Pro*C で作成されたのは、非常にファンキーな処理またはレポートだけでした。
他の人がほのめかしたように、これらをストアド プロシージャとして記述する必要はありません。シェル スクリプトのように、必要に応じて実行される単なるスクリプト ファイルにすることができます。また、ソース コードのリビジョン管理と、テスト システムと本番システムの間の移行も非常に簡単になります。
C# と SQL を使用してバッチ プログラムを作成しました。
C# の長所:
C# の短所:
SQL の利点:
SQL の短所:
一般に、上記の長所があるため、SQL の使用に固執します。
実行する必要のある計算が適切かつ読みやすい形で PL/SQL に取り込まれる限り、PL/SQL のみを使用することが最も理にかなっています。
本当の問題は保守性です。単純な SQL DML の外に出ると、すべての RDBMS が異なる構文と異なる関数セットを持ち、書式設定の実際の標準がないという理由だけで、保守不可能な SQL を書くのは非常に簡単です。コメントなど。
これはよくある質問です :) 知っておくべきデータベース プログラミング アーキテクチャの設計がいくつかあり、そのコストと利点は何ですか。2 層とは、通常、クライアントが DB に接続し、直接 SQL 呼び出しを発行することを意味します。3 層とは、通常、DB に直接 SQL 呼び出しを発行している「アプリケーション サーバー」があることを意味しますが、クライアントはアプリ サーバーと通信しています。通常、これにより「スケールアウト」が可能になります。最後に、2 層のような形式を採用する 2 1/2 層のアプリがあり、作業のみがストアド プロシージャ内で区分化されます。
あなたのプロセスは「バックオフィス」のようなものに聞こえます.クライアント/プロセスは、月に1回集計されてキャッシュされる結果を必要とするだけです. つまり、接続し、頻繁に接続し、「これらの計算を実行してください」と言うエージェントはありません。代わりに、たまに発生するプロセスをほのめかし、非リアルタイムで逃げることができます.
したがって、これらの要件を考えると、一般的には、データに近づき、SQL サーバーにすべての計算を任せる方が高速であると言えます。データへの近さがあなたに役立つことがわかると思います。
ただし、これらの計算を実行すると、一部の計算が SQL Server に適していないことに気付く場合があります。たとえば、債券や債券の未収利息の計算を考えてみましょう。SQL ではあまりきれいではなく、よりリッチなプログラミング言語に適しています。ただし、単純な平均やその他の比較的健全な集計がある場合は、SQL 側でストアド プロシージャに固執します。
繰り返しますが、あなたの計算の性質、またはサポートのための開発者の SQL 機能に関してあなたの家が何を義務付けているか、またはあなたの上司が何を言っているのかについての十分な情報はありません...しかし、私は SQL の使い方を知っているので、データの近くにいて、このようなタスクには純粋な SQL/ストアド プロシージャを使用します。
YMMV :)
ほとんどのストアド プロシージャ言語は設計上うまくいかないため、通常はより表現力豊かではありません。ただし、おそらく外部アプリよりも高速に実行されます。
要するに、あなたがPL/SQLにどれだけ精通しているか、これを書くのにどれくらいの時間が必要か、パフォーマンスがどれほど重要か、そしてメンテナーがPL/SQLで書かれた大きなプログラムを維持するのに十分なほど精通していると合理的に期待できるかどうかにかかっていると思います。それ。
速度が関係なく、メンテナーが PL/SQL に精通していない可能性が高い場合は、「伝統的な」言語を使用する方がよいかもしれません。
PL/SQL を使用して中間データ (たとえば、テーブルの結合や合計など) を生成し、別のアプリケーションを使用してフローを制御し、値とエラーをチェックするハイブリッド アプローチを使用することもできます。