2. ストアド プロシージャの役割はリソースの消費だけではありません。ここで、プログラムには 2 つのログイン方法があります。1 つは Web 側でログインする方法、もう 1 つはネイティブ クライアント側でログインする方法です。 Web 側は Java Web を使用して実装され、クライアント側は Visual C++ を使用して実装されると仮定します。 Java Web と Visual C++ の両方がログイン時に login_user_and_result() を呼び出す場合、ユーザーの一貫したログイン動作が維持され、開発者は個別の実装によって引き起こされる他の問題を回避できます。実際、ストアド プロシージャにさまざまなデータベース レベルのアクセス許可を追加して、ログイン アクセス許可を均一に制御することもできます。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
1. ストアド プロシージャは非常に便利です。たとえば、一般的なログイン シナリオでは、ユーザーのログイン レコードを記録する必要があります。これを実現するには、プログラミング言語を使用できます。 リーリー
ここでは、まずステップ 1 でユーザーが存在するかどうかを判断し、ステップ 2 でユーザーのログイン ログを記録します。
ストアド プロシージャの実装:login_user_and_save_result() の機能は、ユーザーのログイン操作を実行し、ユーザーのログイン ログを記録することです。リーリー
違いは、プログラミング言語の実装には 2 つのデータベース接続接続操作と 2 つのコンパイル SQL 操作が必要であることです。パラメータを渡すだけです。このように、ユーザー数が徐々に増加するにつれて、ストアドプロセスはサーバーの帯域幅とシステムリソースの消費を大幅に節約でき、その利点が徐々に現れます。
上司がロジック層の追加を要求した場合、ユーザーは 3 回のみログインを許可され、3 回失敗するとログインできなくなります。プログラミング言語レベルでのデータベース操作は少し複雑になります。リーリー
ここで、プログラミング言語がデータベースに頻繁に接続するか、データベースとのネットワーク接続を長期間維持する必要があることがわかります。これらすべてのログイン ロジックを login_user_and_result() に実装すると、パラメータ username と pass を渡すだけで済み、システムは DB に 1 回接続し、コンパイルを 0 回行うだけで済み、はるかに簡単になります。
2. ストアド プロシージャの役割はリソースの消費だけではありません。ここで、プログラムには 2 つのログイン方法があります。1 つは Web 側でログインする方法、もう 1 つはネイティブ クライアント側でログインする方法です。 Web 側は Java Web を使用して実装され、クライアント側は Visual C++ を使用して実装されると仮定します。 Java Web と Visual C++ の両方がログイン時に login_user_and_result() を呼び出す場合、ユーザーの一貫したログイン動作が維持され、開発者は個別の実装によって引き起こされる他の問題を回避できます。実際、ストアド プロシージャにさまざまなデータベース レベルのアクセス許可を追加して、ログイン アクセス許可を均一に制御することもできます。ストアド プロシージャには 2 つの主な利点があると思います。まず、ネットワーク通信のオーバーヘッドを回避するためにデータベース側で実行され、効率が向上します。第 2 に、ストアド プロシージャは、トランザクション、トリガー、書き換えルールなど、データベースによって提供されるいくつかの高レベルの抽象化を直接利用できます。
ストアド プロシージャをまったく使用しない場合、データベースは追加、削除、変更を提供する単なるストレージ バックエンドであり、データベースが提供する高度な機能は無駄になります。ストアド プロシージャを使用してビジネス関数を構築すると、フロント エンドは API の効果と同様に、これらの関数を呼び出すだけです。
実装、運用、保守は自分で変更できますが、そうでない場合、大企業の場合は開発側に戻ってコードを変更し、コンパイルしてパッチを発行する必要があります
私のプロジェクトではストアド プロシージャは使用されていません。ビューを利用させていただきました！大規模なプロジェクトを抱える企業には、必要に応じて専用の DBA ユニットが存在する場合があります。
ODS、データ ウェアハウスなどの従来のデータセンターでのデータ バッチ処理、または OLA では、引き続きストアド プロシージャが使用されます
一部の DBA はストアド プロシージャや単純なロジックを使用し、ログはデータベースに書き込まれます...個人的には、ログをコードに記述する方が簡単だと思います
効率が高く、責任が非常に細かい場合、バックエンドがデータベースに自由にアクセスできない場合があります
私のプロジェクトでは、特にレポートでストアド プロシージャが頻繁に使用されており、そのほとんどでストアド プロシージャが使用されています。
上記の利点に加えて、クロスデータベース、サブテーブルユニオン、SQL の動的スプライシングなど、ストアドプロシージャのスケーラビリティが向上します。ストアドプロシージャは便利で直感的であり、使用されることもあります。将来の配布のために、ストアド プロシージャ内で変更を結合するだけです。
私は通常、データの並べ替えと移行に使用します。たとえば、Web サイトが修正された場合、データ構造が変更された場合、特定のテーブルが分割された場合、特定のテーブルが結合された場合、特定のフィールドのデータ形式が変更された場合など。とにかく、サイトがアップグレードされた場合にのみ使用する必要があります。一般にコードを使用して実装できる他のクエリは、ストアド プロシージャを使用して実装する必要はありません
評判の良い企業は DBA のような立場にあり、プログラマが書いた SQL を軽視し、複雑なビジネスを実装するために何千行ものストアド プロシージャを作成します。
ストアド プロシージャ自体の利点については詳しく説明されていません。