菜鳥学データベース(三)――ストレージプロセス
今日は私たちのSQL菜鳥チュートリアルを続けて、前編のブログはトリガ(SQL菜鳥入門レベルチュートリアルのトリガ)を言って、今日はストレージプロセスについて話します.実際には、トリガもストレージ・プロシージャに属しますが、特殊です.次は本題に入り、菜鳥たちを率いてストレージプロセスを勉強させていただきます.
ストレージ・プロシージャの概要
ストアド・プロシージャ(Stored Procedure)は、特定の機能を達成するためのSQL文セットのセットであり、コンパイルされた後にデータベースに格納され、ユーザーはストアド・プロシージャの名前を指定し、パラメータ(ストアド・プロシージャにパラメータがある場合)を与えることによって実行します.データベース・システムでは、ストレージ・プロシージャとトリガが重要な役割を果たします.ストアド・プロシージャでもトリガでも、SQL文とプロセス制御文のセットです.
ストアド・プロシージャの分類
1システムストレージプロセス
sp_で先頭は、システムの各設定を行うために用いる.情報を取得する関連管理業務.
2ローカル・ストレージ・プロシージャ
ユーザーが作成したストレージ・プロシージャは、ユーザーが特定の機能を作成して完了するストレージ・プロシージャであり、さまざまなプログラミング言語でユーザーが自分で書いた関数と非常に似ています.一般的にストレージ・プロシージャとは、ローカル・ストレージ・プロシージャを指します.今日は、ローカル・ストレージ・プロシージャについて重点的に説明します.他のストレージ・プロシージャについては、ご理解ください.
3一時記憶プロセス
2つのストレージ・プロシージャに分けられます.1つは、tempdbデータベースに格納されたローカル・一時ストレージ・プロシージャであり、作成したユーザーのみが実行できるローカル・一時ストレージ・プロシージャです.2つ目は、tempdbデータベースに格納されたグローバル・テンポラリ・ストレージ・プロシージャです.グローバル・テンポラリ・ストレージ・プロシージャが作成されると、サーバに接続された任意のユーザーが実行でき、特定の権限は必要ありません.
4リモート・ストレージ・プロシージャ
SQL Server 2005では、リモート・ストレージ・プロシージャ(Remote Stored Procedures)はリモート・サーバ上に存在するストレージ・プロシージャであり、通常、分散クエリーおよびEXECUTEコマンドを使用してリモート・ストレージ・プロシージャを実行することができる.
5拡張ストレージ・プロシージャ
拡張ストレージ・プロシージャ(Extended Stored Procedures)は、外部プログラム言語を使用してユーザーが作成できるストレージ・プロシージャであり、拡張ストレージ・プロシージャの名前は通常xp_はじめに.
ストアド・プロシージャの基本コード構造を作成するには、次の手順に従います.
メリット
1.ストレージ・プロシージャは、作成時にのみコンパイルされます.その後、ストレージ・プロシージャを実行するたびに再コンパイルする必要はありません.通常、SQL文は実行するたびにコンパイルされるので、ストレージ・プロシージャを使用するとデータベースの実行速度が向上します.
2.データベースに対して複雑な操作を行う場合(複数のテーブルに対してUpdate,Insert,Query,Deleteを行う場合など)、この複雑な操作をストレージ・プロシージャでカプセル化してデータベースが提供するトランザクションと組み合わせて使用できます.
3.ストレージ・プロシージャは繰り返し使用でき、データベース開発者のワークロードを削減できます(多重性が高く、オブジェクト向けのプログラミング・アイデア)
4.セキュリティが高く、特定のストレージ・プロシージャの使用権を持つユーザーのみを設定できます.
欠点
1.デバッグは面倒ですが、PL/SQL Developerでデバッグするのは便利です!この欠点を補う.
2.移行の問題は、データベース・エンド・コードがデータベースに関連していることは当然です.しかし、エンジニアリング型のプロジェクトであれば、移植の問題はほとんどありません.
3.バックエンド・コードは実行前にコンパイルされているため、参照関係のあるオブジェクトが変更された場合、影響を受けるストレージ・プロシージャ、パケットは再コンパイルする必要があります(ただし、実行時刻自動コンパイルに設定することもできます).
4.1つのプログラムシステムでストレージ・プロシージャを大量に使用すると、プログラムが提供されるまでユーザーのニーズが増加するにつれてデータ構造が変化し、次にシステムに関する問題が発生します.最後に、ユーザーがシステムを維持するのは難しいと言えますが、コストは空前のもので、メンテナンスがさらに面倒になります.
世の中のすべての物事はすべて両面性があって、绝対に良いものがなくて、绝対に悪いものもありません.ストレージ・プロシージャにはメリットもデメリットもあります.ストレージ・プロシージャを盲目的に完全に使用することはできません.また、それを冷遇して使用しないことはできません.具体的なプロジェクトによって、実際の状況に応じてストレージ・プロシージャの使用方法を決定するには、過度にバランスを取らないことが最も重要です.
具体的にどのように衡衡するべきで、私がここで1つの2つの言叶で解决することができるのではありませんて、自分で実践の中で体得しなければならなくて、ゆっくりとその中の火加減を掌握することができます.最後に皆さんが私と同じ菜鳥が一日も早く牛になることを祈っています.愚かな鳥も先に飛ぶことができます!
ストレージ・プロシージャの概要
ストアド・プロシージャ(Stored Procedure)は、特定の機能を達成するためのSQL文セットのセットであり、コンパイルされた後にデータベースに格納され、ユーザーはストアド・プロシージャの名前を指定し、パラメータ(ストアド・プロシージャにパラメータがある場合)を与えることによって実行します.データベース・システムでは、ストレージ・プロシージャとトリガが重要な役割を果たします.ストアド・プロシージャでもトリガでも、SQL文とプロセス制御文のセットです.
ストアド・プロシージャの分類
1システムストレージプロセス
sp_で先頭は、システムの各設定を行うために用いる.情報を取得する関連管理業務.
2ローカル・ストレージ・プロシージャ
ユーザーが作成したストレージ・プロシージャは、ユーザーが特定の機能を作成して完了するストレージ・プロシージャであり、さまざまなプログラミング言語でユーザーが自分で書いた関数と非常に似ています.一般的にストレージ・プロシージャとは、ローカル・ストレージ・プロシージャを指します.今日は、ローカル・ストレージ・プロシージャについて重点的に説明します.他のストレージ・プロシージャについては、ご理解ください.
3一時記憶プロセス
2つのストレージ・プロシージャに分けられます.1つは、tempdbデータベースに格納されたローカル・一時ストレージ・プロシージャであり、作成したユーザーのみが実行できるローカル・一時ストレージ・プロシージャです.2つ目は、tempdbデータベースに格納されたグローバル・テンポラリ・ストレージ・プロシージャです.グローバル・テンポラリ・ストレージ・プロシージャが作成されると、サーバに接続された任意のユーザーが実行でき、特定の権限は必要ありません.
4リモート・ストレージ・プロシージャ
SQL Server 2005では、リモート・ストレージ・プロシージャ(Remote Stored Procedures)はリモート・サーバ上に存在するストレージ・プロシージャであり、通常、分散クエリーおよびEXECUTEコマンドを使用してリモート・ストレージ・プロシージャを実行することができる.
5拡張ストレージ・プロシージャ
拡張ストレージ・プロシージャ(Extended Stored Procedures)は、外部プログラム言語を使用してユーザーが作成できるストレージ・プロシージャであり、拡張ストレージ・プロシージャの名前は通常xp_はじめに.
ストアド・プロシージャの基本コード構造を作成するには、次の手順に従います.
CREATE PROCEDURE Procedure_Name
--Procedure_Name ( )， 。 。PROCEDURE PROC。
@Param1 Datatype,@Param2 Datatype
--@Param1 @Param2 ，Datatype , , 。
AS --
BEGIN
--BEGIN END ， ， SQL ， BEGIN END ， 。
END
GO --GO
exec Procedure_Name [ ] -- Procedure_Name。
drop procedure Procedure_Name -- Procedure_Name， ，
show procedure status -- ， ， ，
show create procedure Procedure_Name -- Procedure_Name
exec sp_helptext Procedure_Name -- Procedure_Name
メリット
1.ストレージ・プロシージャは、作成時にのみコンパイルされます.その後、ストレージ・プロシージャを実行するたびに再コンパイルする必要はありません.通常、SQL文は実行するたびにコンパイルされるので、ストレージ・プロシージャを使用するとデータベースの実行速度が向上します.
2.データベースに対して複雑な操作を行う場合(複数のテーブルに対してUpdate,Insert,Query,Deleteを行う場合など)、この複雑な操作をストレージ・プロシージャでカプセル化してデータベースが提供するトランザクションと組み合わせて使用できます.
3.ストレージ・プロシージャは繰り返し使用でき、データベース開発者のワークロードを削減できます(多重性が高く、オブジェクト向けのプログラミング・アイデア)
4.セキュリティが高く、特定のストレージ・プロシージャの使用権を持つユーザーのみを設定できます.
欠点
1.デバッグは面倒ですが、PL/SQL Developerでデバッグするのは便利です!この欠点を補う.
2.移行の問題は、データベース・エンド・コードがデータベースに関連していることは当然です.しかし、エンジニアリング型のプロジェクトであれば、移植の問題はほとんどありません.
3.バックエンド・コードは実行前にコンパイルされているため、参照関係のあるオブジェクトが変更された場合、影響を受けるストレージ・プロシージャ、パケットは再コンパイルする必要があります(ただし、実行時刻自動コンパイルに設定することもできます).
4.1つのプログラムシステムでストレージ・プロシージャを大量に使用すると、プログラムが提供されるまでユーザーのニーズが増加するにつれてデータ構造が変化し、次にシステムに関する問題が発生します.最後に、ユーザーがシステムを維持するのは難しいと言えますが、コストは空前のもので、メンテナンスがさらに面倒になります.
世の中のすべての物事はすべて両面性があって、绝対に良いものがなくて、绝対に悪いものもありません.ストレージ・プロシージャにはメリットもデメリットもあります.ストレージ・プロシージャを盲目的に完全に使用することはできません.また、それを冷遇して使用しないことはできません.具体的なプロジェクトによって、実際の状況に応じてストレージ・プロシージャの使用方法を決定するには、過度にバランスを取らないことが最も重要です.
具体的にどのように衡衡するべきで、私がここで1つの2つの言叶で解决することができるのではありませんて、自分で実践の中で体得しなければならなくて、ゆっくりとその中の火加減を掌握することができます.最後に皆さんが私と同じ菜鳥が一日も早く牛になることを祈っています.愚かな鳥も先に飛ぶことができます!