https://blog.csdn.net/jesse621/article/details/9452049
フリップフロップ、シンプル、ストアドプロシージャ、およびクリア
使用
トリガーアクション：
主な役割は、参照整合性を可能にし、データを主キーと外部キーの整合性が保証することができない複雑なをトリガすることです。関連するデータベーステーブルが非正規化されたデータと比較データの変更前と後のカスケード、より複雑なデータの整合性よりもCHECK制約力、およびカスタム・アクション・メッセージ、メンテナンス状態を修正するためにそれは可能です。CHECK制約異なるトリガは、テーブル内の他の列を参照することができます。以下の条件の下で、複雑な参照整合性を実装するためにトリガーを使用して、データ間の整合性を必須。あなたは、データの挿入、更新、削除の複数の行は、あなたがトリガーハンドルに複数のデータ行を記述する必要があり、マルチライントリガを作成するとき。カスケード更新やカスケード削除などのアクションを実行します。すべての関連するテーブルのデータベースを変更CASCADE。失効またはロールバックは、データを変更することは違法防ぐために、操作の参照整合性に違反します。
トリガーとストアドプロシージャの違いは：
主な違いは、トリガーとストアドプロシージャモードトリガを実行することです。ユーザは、ディスプレイにアプリケーションストアドプロシージャ、またはトリガを呼び出して実行し、トリガーは、特定の時間の発生で、または自動的に関わらず、データベース内のユーザ、またはアプリケーションとの接続の、活性化されたときに行わなければなりません。行は、挿入、更新、またはトリガが実行された時に削除するだけでなく、トリガが作成される方法に依存し、INSERTは、使用時に発生する削除すると、挿入トリガーを使用して発生した場合、更新トリガの更新が発生した使用された場合削除トリガー。
データベースのストアドプロシージャとトリガについての知識は、これは一般的にはすぐにその使用をマスターする限り、非常に技術的な詳細です。データベースを設計するので、多くの年後、私は通常、彼らはまた、ストアドプロシージャとトリガの多かれ少なかれ使用されます、その理由は非常に単純です：達成するための優れた性能、イェジンハオ事業。最後の項目を実行するときにビジネスは複雑であるため、ストアドプロシージャとトリガの数が何百と達している。しかし、これは特に間違った時のデバッグやメンテナンスに、非常に恐ろしいことですが、私はこれらの事は良いだろうとは思いません。今、私は、ストアドプロシージャとトリガのビューの観点から、経験の一種。
図1に示すように、トリガは特別なストアドプロシージャです。
この文は、多くの場合、それは多くの場合では、引数なしのコールの表示を必要としないので、私の一般的な理解は、隠されたトリガーは、ストアドプロシージャであり、両者は非常に結びついていることを示している、教科書に表示されますあなたの知識がなくても、私は多くのアクションを行っています。それが隠されているので、それはその存在を感じていないだけで実行していないため、このような観点から、潜在的にシステムの複雑さを増す、非DBAの人事データベースは、理解することは難しいだろう。それは、ネストされたトリガの複雑なロジックに来るとき、再び、それはデバッグの際に頻繁にしてます、我々はトランザクションに結合されたいくつかのストアドプロシージャを伴うというように、デッドロックする傾向がある、とあれば、避けられませんカスケードに絶えず遡及トリガ別の1から行く、大きな頭を作ることは簡単です。実際には、パフォーマンス、および多くのパフォーマンスを改善しなかったフリップフロップから、単にコードから、それは私のポイントがあるので、コーディング時に業務を達成するのは簡単かもしれ：トリガーを放棄します！トリガーの基本的な機能は、ストアド・プロシージャを実装するために使用することができます。
2、ストアドプロシージャは、多くの利点があり、頻繁に使用することができます
- ユーザーが開発者だけとデータベース管理者による使用を意図したデータとオブジェクトにアクセスできるように、データ・ロジックとビジネスルールをカプセル化することができます。
- ユーザ入力を検証するための全てのパラメータストアドプロシージャは、SQLインジェクション攻撃を防ぐために使用されてもよいです。あなたは、動的SQLを使用する場合は、のコマンドパラメータに必ず、およびクエリ文字列で直接パラメータ値を含めることはできません。
- これは、アドホッククエリやデータ変更を禁止することができます。これは、データが破損したり、サーバやネットワークのパフォーマンスを低下させないために、クエリを実行誤って、または悪意を持ってからユーザーを防ぐことができます。
- エラーコードは、クライアントアプリケーションにエラーなしで、プロセスに直接送信を処理することができます。この防止は、エラーメッセージを返し、それが検出攻撃を避けるために役立つかもしれません。サーバーエラーとプロセスに記録。
- ストアドプロシージャは一度しか書き込むことができ、多くのアプリケーションにアクセスすることができます。
- クライアント・アプリケーションは、基礎となるデータ構造について何を知っている必要はありません。限り変更は、データ型パラメータリストまたはに戻るには影響しないので、あなたは、クライアントアプリケーションに変更を加える必要なしに、ストアドプロシージャのコードを変更することができます。
- 複数の動作を組み合わせて、ストアド・プロシージャは、ネットワークトラフィックを削減するための呼び出しを処理します。
- あなたが直接、基本となるテーブルを操作する権限を持つストアドプロシージャを実行することなくアクセスすることができます - セキュリティが良いです
- ネットワークトラフィックを削減 - ストアドプロシージャが複数のSQL文を含むことができるが、文限りすることにより、サーバーコール数と長さへのクライアントアプリケーションを減らし、ストアドプロシージャを実行します
- 以下のために再び呼び出されるストアドプロシージャの構文チェックとコンパイル、キャッシュ内の最初の実行中に保存されたコンパイルされたバージョン、 - 高速実行
- 一貫性を確認 - あなただけのストアドプロシージャを介してデータを変更する場合は、オペレータエラーやプログラマを減らすために偶発変更に起因する問題を解消することができます - 以下の情報転送するので、それが簡単に複雑なタスクを実行すること、エラーにSQLが少ない傾向
3、致命的な移植性を考慮して、ストアドプロシージャ
の開発場合、システムは、ストアドプロシージャ、システムがシステムにデータベースのビジネスロジック層で追加の増加を与えるデータベース、に依存しすぎていることを、ビジネス・ロジックを使用するために使用される場合許容できないストアドプロシージャを、書き換えが同等の、非常に面倒なことと思われる、SQL Serverを使用し、以降のデータが大きすぎることが判明し、移植のOracleやMySQLのパフォーマンスを改善する必要がある場合。私たちは通常、プロジェクトを行い、それがクライアントの実装の機能は、それが多くの人々は、サーバ側で行うことを選択しますので、サーバー側で実装するのは簡単ですが、将来は隠された滞在するために、しばしば困難たです。プロジェクトの需要分析は、それがデータの量が少ない場合、アップグレードする可能性がありますどのくらい、パフォーマンスの問題を検討することを確認した場合、問題はないとの数十年のためのSQL Serverは、それがマルチストアドプロシージャを使用することができます。しかし、データの量が徐々に可能性があります千万またはそれ以上まで追加、我々は、システムの可搬性を考慮しなければならない、とこの時間は、ストアドプロシージャ、すべてのコードコントロールを使用しないようにしてください。
図4に示すように、ストアドプロシージャのコードの再利用性が悪いです。
このオブジェクト指向のストアドプロシージャに完全に役に立たない思考は、2つの非常に似た機能はまた、彼らは相互に独立しているので、あなたがお互いを呼び出すことができ、2つのストアドプロシージャが必要ですが、そのようなオブジェクト指向の、手段としてできない継承の操作コードの量を増やします。
要約すると：一般的な小規模システム（シンプルなロジック）に、ストアドプロシージャとトリガは、すべての後に、MSの設計多目的することができ、あなたは主にパフォーマンスを向上させることができ、複雑なシステムでは、我々はより少ない、トリガなしでストアドプロシージャをお勧めします。