java - ストアドプロシージャを削除して、Javaプログラムからデータベース呼び出しを実行する必要があります

Question

社内でストアドプロシージャを使い続けるために戦っています。悪いと言う人もいるので、使ってはいけません。iシリーズではDB2を使用しています。

私の会社でストアドプロシージャを存続させるための私の議論を手伝ってください。

Answer 1

あなたはこれを気に入らないでしょう、そして私はおそらく忘却に反対票を投じるでしょう、しかし私はあなたの仲間の残りの人たちと一緒です。

ストアドプロシージャは多くの利点（セキュリティ、パフォーマンスなど）を提供するために使用されていましたが、パラメータ化されたクエリとより優れたクエリ最適化により、ストアドプロシージャは実際にはアプリケーションにオーバーヘッドの別の層を追加し、コードを更新/変更する必要がある別の場所を提供します。

コードを編集する必要があるときに、1つの場所に移動してそこで変更を加えることができるように、すべてを1か所にまとめることを好みます。

Stored Prcoeduresから離れるための議論についての詳細が必要な場合は、次のCodingHorrorの記事を確認してください。

コーディングホラー：とにかくストアドプロシージャが必要なのは誰ですか？

...そして私はちょうどその記事が2004年のものであることに気づきました。それ以来データベースが良くなっていると信じなければなりません。

Answer 2

これは、マーマイトの問題の1つです。主にデータベースプログラマーである場合は、ストアドプロシージャを広範囲に使用する必要があると考えるでしょう。あなたがアプリケーションプログラマーである場合（たとえば、Javaまたは.Netコーダー）、それらは完全に避けるべきであると言う可能性があります。

これは、アプリケーションプログラマーが独自のSQLステートメントを記述したいということを満たしているわけではありません。いいえ、最近では、複雑なORMサービスの背後にあるすべてのものを抽象化する傾向があります。これらはストアドプロシージャよりも理解しやすいものではありませんが、同じIDE内で使用できるため、コンテキストの切り替えが少なくて済みます。

ストアドプロシージャを支持する2つの大きなことがあります。1つ目は、PL / SQLを知っている人はOracleデータベース（T-SQLやSQL Serverなど）に精通している可能性が高いため、そのデータベース用のより優れたプログラム（プラットフォームを利用するプログラムとして定義）を作成する傾向があるということです。機能とその機能に適合している）そうでない人よりも。

2つ目は、データが保持されることです。アプリケーション開発者は「データベースの独立性」について話すのが好きですが、本当に重要なのはアプリケーションの独立性です。フロントエンドは行き来しますが、データモデルは永遠に存続します。過去10年間で、Javaアプリケーションはアプレット、サーブレット、JSP、タイル、フェイスとして作成され、JavaScript、Groovy、AJAX、JSONのアドオンが追加され、手動でロールされたJDBC、EJB（v1,2、 3）、TopLink、Hibernate、およびIBatis ...いくつか見逃した場合は、ご容赦ください。UIがストアドプロシージャのレイヤーのスキンであるアプリケーションは、ビジネスロジックを毎回書き直す必要があるアプリケーションよりも、最新かつ最高のアプリケーションに簡単にアップグレードできます。そして、彼らもより良いパフォーマンスを発揮します。

ただし、長期的には、データベースと直接対話するアプリケーションはおそらく消滅します。すべてがサービスバスと通信し、どこからデータを取得するかが決まります。もちろん、ストアドプロシージャの適切に設計されたAPIを介してデータベースが公開されているショップは、ORMロジックからすべてを抽出する必要がある場所よりも、この勇敢な新しい世界に移動する方が簡単な場合があります。

Answer 3

すべてを JDBC 経由で行うということは、基本的に、ユーザーとデータベースの間にネットワーク層を挿入していることを意味します。全体として、データがより「リモート」になり、データが遅くなることを意味します。ストアド プロシージャは、データベース内のデータを直接操作できるため、結果として得られる速度の違いに驚くかもしれません。

プログラミングのスキルがあれば、Java を含む任意の IBM i 言語でストアード・プロシージャーを作成できることに注意してください。また、一部のデータベース内部だけでなく、完全なマシンにアクセスできます。ここで、AS/400 は他のどのデータベース製品とも大きく異なるため、他のデータベースでの経験は単純に (私の意見では) 当てはまりません。

私が知っている AS/400 プログラミング スキルが最も集中しているミッドレンジ メーリング リストをお勧めします。

Answer 4

OK、私はストアド プロシージャを支持します。

まず、それらを排他的に使用すると、データベースに保存されている依存関係を使用して、変更によって何が影響を受けるかを調べることができるため、データベースのリファクタリングがはるかに簡単になります (とにかく SQL Server では、他のデータベースについて話すことはできません)。

次に、クエリだけを変更する必要がある場合は、デプロイがはるかに簡単です。

また、アプリケーションを起動せずに簡単に呼び出すことができるため、パフォーマンスの調整も容易です。

複雑なロジックがある場合は、そのすべてをネットワーク経由でデータベース サーバーに送信する必要がないため、パフォーマンスをいくらか節約できます。大きな利益とは思えないかもしれませんが、複雑なクエリが 1 日に何千回も実行されると、合計される可能性があります。

セキュリティも非常に重要です。ストア プロシージャを使用しない場合は、テーブルまたはビュー レベルで権限を設定する必要があります。これにより、データベースが内部不正にさらされます。確かに、パラメーター化されたクエリは SQL インジェクションのリスクを軽減しますが、防御する必要がある脅威はそれだけではありません。個人データまたは財務データがあり、ストアド プロシージャ (および動的 SQl を持たないもの) を使用せず、ユーザーがそのプロシージャを介してのみ実行できるように制限している場合、システムは盗む可能性のある内部従業員から非常に危険にさらされています。データを盗んだり、内部統制をバイパスしてお金を盗んだりします。会計基準の内部統制について読んで、これが問題である理由を確認してください。

また、ORM は、特にクエリが複雑な場合、まったく悪い SQL コードを記述する傾向があります。さらに、人々がストアド プロシージャの代わりにストアド プロシージャを使用し始めると、ストアド プロシージャを使用したことがない人は、データベースからデータを取得する方法をよく理解しておらず、頻繁に間違ったデータを取得することがわかりました。すでに SQL を理解しており、自動生成されたコードをより適切に機能するコードに書き換えるタイミングを判断できる場合は、ORM を使用しても問題ありません。しかし、基本を学んだことがないため、複雑なコードを書くスキルを持っていないユーザーが多すぎます。

最後に、アプリケーションのストアド プロシージャは既にあるため、それらを完全に削除すると、新しいコードを生成する必要があるため、新しいバグが発生する可能性があります。

Answer 5

これらは、階層化された一連のアプリがある場合に役立ちます。たとえば、アトミック操作 (たまたまストアド プロシージャ) を提供する Web サービスを備えた単一のコア DB と、これらの WS を使用する ESB または一連のアプリケーションです。単一アプリ/単一データベースの場合、アイデアは、他の人が提案したようにコードを 1 か所に保持することです。

しかし、まあ、それは私だけです。

Answer 6

私は長年の Java 開発者ですが、最近、ストアド プロシージャを多用するいくつかのプロジェクトに出くわしました。

そうは言っても、システム設計オプションとしてストアド プロシージャが悪いと一概に述べるのは気が進まない。実際には、問題のプロジェクトと、特定のストアド プロシージャが何を達成しようとしているかに依存するからである。

私の好みは、単純な CRUD 操作にはストアド プロシージャを使用しないことです (ストアド プロシージャにこれらの操作を処理させるのはばかげているように聞こえるかもしれませんが、これを実行しているいくつかのシステムに遭遇しました)。私が観察したところによると、これらのプロシージャー・コールを管理するために Java 側でコードを作成 (およびテストおよび保守) する必要があります。これらの種類の操作を処理するには、Hibernate (またはその他の ORM ライブラリ) を使用することをお勧めします...維持する必要があるコードの量を減らす傾向があること以外の理由がない場合。クラス/テーブルの変更だけでなく、CRUD操作を処理するストアドプロシージャも考慮する必要があるため、システムをリファクタリングまたは大幅に変更しようとすると問題が発生する可能性があります。

一方、Java コードとの限られた対話を必要とするストアド プロシージャ (基本的には、いくつかの引数を指定して呼び出しを開始するだけ) を使用し、半自律的な方法で実行することも、ひどいことではありません。私はいくつかの状況 (特に、データをシステムに移行またはインポートする場合) に遭遇しました。機能を処理するために多数の Java コードを記述するよりも、ストアド プロシージャを使用する方がはるかに優れた方法でした。

ここでの本当の答えは、システム内の各ストア プロシージャが現在何を行っているかを調べ、ケースバイケースで評価して、Java またはデータベースで操作を処理する方が簡単かどうかを判断する必要があるということでしょう。Java で (ORM ライブラリまたは実際の手書きコードによって) うまく機能するものもあれば、そうでないものもあります。どちらの場合でも、目標は、ストアド プロシージャ自体の良し悪しだけでなく、誰にとっても理解しやすく、保守しやすいシステムにすることです。