私は約 6 年間、Web/デスクトップ アプリケーションを開発しています。私のキャリアの過程で、ストアド プロシージャを使用してデータベースに大量に記述されたアプリケーションに出くわしましたが、多くのアプリケーションでは、エンティティごとに (エンティティ レコードの読み取り、挿入、編集、および削除を行うための) いくつかの基本的なストアド プロシージャしかありませんでした。 .
エンタープライズ データベースに料金を支払った場合は、その機能を広範囲に使用できると主張する人を見てきました。多くの「オブジェクト指向アーキテクト」は、データベースに必要以上のものを入れるのは絶対的な犯罪であり、それらのクラスのメソッドを使用してアプリケーションを駆動できるはずだと私に言いましたか?
バランスはどこにあると思いますか？
ありがとう、クルーナル
ビジネスロジックとデータロジックの問題だと思います。データの一貫性を保証するロジックがある場合は、それをストアド プロシージャに入れます。データ取得・更新の便利機能も同様です。
他のすべてはコードに入る必要があります。
私の友人は、バイオインフォマティクスのデータ分析アルゴリズム用の多数のストアド プロシージャを開発しています。彼のアプローチは非常に興味深いと思いますが、長期的には正しい方法ではありません。私の主な異議は、保守性と適応性の欠如です。
私はオブジェクト指向アーキテクトの陣営にいます。それに伴う警告を理解している限り、コードをデータベースに入れることは必ずしも犯罪ではありません。ここにあるいくつかの：
参照整合性または一貫性に関連するものはすべて、最低限データベースに含める必要があります。それがアプリケーション内にあり、誰かがデータベースに対してアプリケーションを作成したい場合、データの一貫性を保つために、コード内でコードを複製する必要があります。
PLSQL for Oracle は、データベースにアクセスするための非常に優れた言語であり、パフォーマンスを向上させることもできます。データベースのストアド プロシージャを「ブラック ボックス」として扱うことができるため、アプリケーションをより「きれい」にすることもできます。
sproc 自体は、コンパイル済みのアプリケーションに近づかなくても調整および変更できます。これは、アプリケーションのサプライヤが廃業したり、利用できない場合にも役立ちます。
「すべて」がデータベースにあるべきだと主張しているわけではありません。それぞれのケースを別々に論理的に扱うと、アプリに入れるかデータベースに入れるか、どちらがより理にかなっているのかがわかります。
私はほぼ同じ背景から来ており、同じ議論を聞いてきました。私は、ロジックをデータベースに入れる非常に正当な理由があることを理解しています。ただし、アプリケーションのタイプとデータの処理方法によって、どのアプローチを選択する必要があるかが異なります。
私の経験では、一部の顧客 (または xyz) 管理のような典型的なデータ入力アプリは、ORM レイヤーを使用することで大きなメリットを得ることができます。これは、データにさまざまなビューがあまりなく、ボイラープレートの CRUD コードを最小限に抑えることができるためです。
一方、多くのテーブルにまたがる多くの同時実行と計算を行い、ロックなどを使用したきめ細かい列レベルのセキュリティ概念を持つアプリケーションがあると仮定すると、おそらく次のようなことを行う方がよいでしょう。データベースに直接。
前述のように、データに対して予想されるさまざまなビューにも依存します。ユーザーに表示する必要がある列とテーブルのさまざまな組み合わせが多数ある場合は、オブジェクトを 1 つずつ別の表現にマップするよりも、さまざまな結果セットを返す方がよい場合もあります。
結局のところ、データベースはセットを扱うのが得意ですが、OO コードは単一のエンティティを扱うのが得意です。
これらの回答を読んで、データベース プログラミングを理解していないことにかなり混乱しています。私は Oracle Pl/sql 開発者で、データベースに入るすべてのコードのソース管理を行っています。IDE の多くは、主要なソース管理製品のほとんどにアドインを提供します。ClearCase から SourceSafe へ。私たちが使用する Oracle ツールを使用すると、コードをデバッグできるので、デバッグは問題になりません。問題は、ロジックとアクセシビリティです。
約 5000 人のユーザーをサポートするマネージャーとして、ロジックを探す場所が少なければ少ないほど良いと思います。ビジネスロジックを含め、データを使用するすべてのアプリケーションにロジックが適用されていることを確認したい場合は、DBに入れます。アプリケーションによってロジックが異なる場合は、責任を負うことができます。
@ダニースマーフ:
デバッグ可能ではありません
サーバーによっては、はい、デバッグ可能です。これは、SQL Server 2000 の例です。最近のはこれもあると思います。ただし、無料の MySQL サーバーにはこれがありません (私の知る限り)。
ソース管理の対象ではありません
はい、そうです。すこし。データベースのバックアップには、ストアド プロシージャを含める必要があります。これらのバックアップ ファイルは、バージョン コントロール リポジトリにある場合とない場合があります。いずれにしても、ストアド プロシージャのバックアップがあります。
私の個人的な好みは、できるだけ多くのロジックと構成をデータベースから除外することです。私は最近、Spring と Hibernate に大きく依存しているため、非常に簡単です。私は、Spring アプリケーション コンテキスト XML ファイルのストアド プロシージャと静的構成情報の代わりに、Hibernate の名前付きクエリを使用する傾向があります。データベースに入れる必要があるものはすべて、スクリプトを使用してロードする必要があり、それらのスクリプトはバージョン管理されています。
@Thomas Owens: (リソース管理) はい。ただし、.cs ファイル (または .cpp ファイルなど) をチェックインして必要なリビジョンを選択できるのと同じ意味でのソース管理ではありません。データベース コードでこれを行うには、データベースからプロシージャを取得してソース ツリーのどこかに転送するか、マイナーな変更が行われるたびにデータベースのバックアップを実行するために、かなりの労力が必要になる可能性があります。どちらの場合も (労力の量に関係なく)、直感的ではありません。また、多くのショップにとって、それは十分な解決策ではありません。また、リビジョンを取得してチェックインするのを忘れる開発者が他の開発者ほど熱心ではない可能性もあります。ソース管理に何でも入れることは技術的に可能です。ここでの切断は、私が問題にするものです。
(再デバッグ可能) それはアプリケーションの残りの部分 (コードの大部分が存在する可能性がある場所) との統合をあまり提供しませんが、まあまあです。それは重要かもしれないし、そうでないかもしれません。
データの一貫性を重視するのであれば、データベース内にコードを実装する理由があります。他の人が言ったように、データベース内にコード (および/または RI/制約) を配置すると、データ自体の近くでビジネス ロジックを強制するように機能します。また、共通のカプセル化されたインターフェイスを提供するため、新しい開発者が孤立したレコードや一貫性のないデータを誤って作成することはありません。
うーん、これは難しい。プログラマーは、TSQL やそのような「データベース言語」をできるだけ避けたいと思うでしょう。なぜなら、それらは恐ろしく、デバッグが難しく、拡張性がなく、それらを使ってできることとできないことは何もないからです。アプリケーションでコードを使用する。
ストアド プロシージャを作成する唯一の理由は次のとおりです。
ただし、ほとんどのアプリケーションでは、コードをデバッグできるアプリケーションに保持し、バージョン管理下に置き、言語によって提供されるすべてのツールを使用して修正するようにしてください。