2

最初にデータベースを始めたとき、私は SQL Server を使用していました。私はもともとクラシック ASP でそれに取り組みました。私たちが言われた大きなことの 1 つは、ストアド プロシージャを使用すると、ASP SQL コマンドを操作するよりも SQL トランザクションで多くの時間を節約できるということでした (「インライン」で実行すると思います)。そのため、ストアド プロシージャを作成し、コードからストアド プロシージャを呼び出して、データベースでやりたいことのほとんどすべてを行いました。

とにかく、数年早送りして、今ではすべての作業を PHP と MySQL (および少しの Python) で行っています。ストアド プロシージャや関数を使用している人はほとんど見かけないので、あまり気にしていません。

しかし、私はそれを間違っているだけで、それに気づいていないことに気づきました。MySQL でストアド関数を使用することに大きな利点はありますか? データベースへの多くの呼び出しを処理するかなりのサイズの Web サイトを構築しています。呼び出しはすべて、私の PHP コードとインラインで行われます。一貫して行っている呼び出しにストアド関数を使用し、変数を PHP から関数に渡すだけのほうがよいでしょうか?

4

2 に答える 2

4

まあそれは依存します。ストアド プロシージャは機能分解を処理する方法であり、複数のアプリケーションが同じデータベースと対話する場合に不可欠です。ストアド プロキュアをすべてに使用するというアイデアは、数年前に優勢でしたが、世界がサービス/RAD の世界に移行したため、その地位を失いつつあります。

ストアド プロシージャの利点のいくつかは次のとおりです。

  1. 再利用 / これは確かにコード ベース内で実現できますが、同じクエリを 10 個のサブ ジョインで 15 回書くよりもはるかに優れています。

  2. セキュリティ - sp が激怒したとき、SQL インジェクション攻撃が前面に出てきました。露出を減らす 1 つの方法は、ほとんどの場合、入力を自動的にサニタイズするパラメータ化された sp を提供することです。

  3. 非常に大規模なデータベース テーブル レイアウトの定義によるドキュメントは、保存しているものとその理由を説明するのに必ずしも十分ではありません。

  4. 定義されたインターフェイス。

これらの長所はすべて、優れたアプリケーション設計を前提として提供でき、ある程度の規模のプロジェクトである程度しかシーンを作成できないと思います.

いくつかの短所

  1. 冗長な機能 - ビジネス ロジックと基本的なロジックがアプリケーションに分散され、ビジネス ロジックがデータベースにある多くのショップを見てきました。

  2. SP の構成管理の欠如 -- コード用の手順とツールは確立されていますが、SP 管理は大幅に遅れています。

于 2011-04-26T17:56:14.197 に答える
0

これは、「コードをメソッド/関数/プロシージャに分割して呼び出す必要があるか、それともすべてを現在の関数にコーディングする必要があるか?」と尋ねるのと同じ質問です。

ストアド プロシージャを使用すると、次のような利点があります。

  1. より簡単なテスト。アプリを実行せずにストアド プロシージャをテストできます。
  2. より簡単な開発。DB 開発者にストアド プロシージャを記述させ、GUI 開発者に UI などを記述させることができます。
  3. 別のデータベースへの移植が容易になります。変更はすべてデータベースに含まれており、アプリとのコントラクト (ストアド プロシージャに渡されるパラメーター) は変更されません。
  4. 複数のフロント エンドからストアド プロシージャのロジックを使用する機能。新しい顧客を作成する必要があるすべてのアプリで、同じ顧客作成ロジックをコーディングする必要はありません。

大きな欠点は、複数の分野を学び、おそらく複数のツールを使用する必要があることです。これは、.Net で Linq for SQL を使用する大きな理由の 1 つです。SQL を学ぶ必要はなく、すべてが .Net コードに含まれています。

すべてにストアド プロシージャを使用します。それは非常にうまく機能します。抽象化はあなたの友達です。

于 2011-04-26T18:00:32.500 に答える