ストアドプロシージャのポイントは何ですか？

Question

これはデータベース管理者以外の人にとって役に立ちますか？私がそれらを正しく理解すれば、それは単にMySQLに直接保存できるクエリなので、どのWeb開発チームでもそれらを使用することは無意味です。

Answer 1

ストアドプロシージャは、データベースサーバー上で実行されるコードです。

これらは多くの用途があります。考えてみましょう：データベースサーバー上で直接コードを実行できるのであれば、どのように使用できますか？それらの多くの用途の中でも

、ストアドプロシージャは、に、データベースサーバからシフト処理負荷の一部をするために使用することができ、ネットワークトラフィックを削減とセキュリティを向上させます。ライブラリ関数とストアドプロシージャの

http://en.wikipedia.org/wiki/Stored_procedure

Answer 2

ストアドプロシージャは、単にデータベースに問い合わせるだけではありません。これらは、任意のT-SQLステートメントを含むことができます。ビジネスロジックの実行、クエリの実行、バックアップの実行などに使用できます。

多くの企業では、すべてのデータベースアクティビティがストアドプロシージャを使用して実行されるというポリシーがあります。ですから、今のところ、Web開発チームはそれらのために役に立たないと言います。彼らはそれらを大いに活用するかもしれない。

一方、私たちの会社では、次世代の製造アプリケーションにそのほとんどを使用していません。代わりにORM（Linq-To-SQL）を使用していますが、現時点ではストアドプロシージャの使用はほとんどありません。サーバーに何度も行き来するのを避けるために、やはりいくらか使っていきたいと思う。いずれにしても、サーバ上ですでに作業をしている場合は、ストアドプロシージャで処理を行うほうが効率的です。

Answer 3

通常のプログラムの手順と考えてください。単一の呼び出しメソッドの下でロジックのチャンクをカプセル化する方法。

プログラムの機能が役に立たないと考えると、この会話はここで終了します。彼らが有用だと思うなら、どちらにも行く場所はありません。あなたがそれらを使うよう強制するものはありませんが、あなたが選択する必要がある場合は利用可能です。

Answer 4

90年代になって、誰でもデータテーブルに直接アクセスできないようにするには、ストアドプロシージャが最も安全な方法でした。

最初はセキュリティ上の問題に対処する可能性が高くなりました。第2に、今日のようなORMツールがないため、データを扱うことがより簡単になるようになっています。

今日では、複雑な取引を主な目的としています。私が複雑なことを言うとき、私は、NHibernateまたはEntity Frameworkのような簡単なCRUD操作では解決できないことを意味します。

ので、ストアドプロシージャのみSELECT、INSERT、UPDATEまたはDELETEを実行するとき、あなたはORMツールを介してこれらの基本的な繰り返し動作を行うことができますよう、彼らは、何とか今無用であることを正しいかもしれません。しかし、レポートを作成しなければならない場合（例えば、必然的な情報データや実行されたその他の計算など）、結果が計算するのがかなり複雑な場合は、データベースエンジンをそのまま動作させる方がよいそのようなデータを計算するように設計されています。

Answer 5

と思います。平方根を計算する必要があるたびにsqrt（たとえば）を書き直したいのですか、それを行う関数を呼び出すのですか？

これは、ストアドプロシージャの利点です（一言で言うと）。

Answer 6

ストアドプロシージャには多くの利点があります。とりわけ、データベース・テーブルからアプリケーション・コードを分離し、データベースのメンテナンスとバージョニングを簡略化し、問合せのパラメータ化、最適化、セキュリティなどのDBMS機能を最大限に活用するのに役立ちます。

任意のWeb 開発チームは

はぁ、それらを使用することは役に立たないだろうか？ストアドプロシージャは、それらをサポートするデータベースを使用する必要がある開発者にとって非常に便利です。

Answer 7

私はそれらを正しく理解していれば、 単にそれがそれらを使用するには、任意のWeb開発チーム ため 役に立たないだろうので、それは、MySQLのに直接 を保存することができ照会しています。

このような（限定された）定義であっても、Web開発チームはデータベースを照会する必要がないことを意味していますか？本当に？

よく書かれたストアドプロシージャセットは、クライアントアプリケーションからクエリを完全に削除し、そのすべてをプロシージャの呼び出しで置き換えることができます。さて、私はそれが、物事を行う唯一の方法、あるいは正しい方法であると言っているわけではありません。全体的に起こっていることについては、かなりdiscussionです。しかし、それはそれらを使用する非常に有効な方法です。

webdevチームにとって役に立たないですか？

Answer 8

ここでは他の回答に記載されていない2良い、シンプルな利点は以下のとおりです。

• セキュリティ - パラメータ化ストアドプロシージャは、しかし、（これにおよそ百万のドキュメントをGoogle SQLインジェクション）SQLの文字列をcontencatingよりも安全です、あなたの言語がそれらをサポートしている場合は、パラメータ化されたクエリもこれに適しています
• メンテナンスの簡素化 - コードを再コンパイルして再デプロイするよりもストアドプロシージャを更新するほうが簡単です。私の15年間の発展の中で私はこれを難しい方法で学んできました。クエリが変更される可能性がある場合は、ストアドプロシージャに配置します。 SOOOはコードを再コンパイルして再デプロイするよりもはるかに簡単です。

は、彼らはまた、ネットワークのチャタリングを軽減

を追加しました。あなたが実行する複雑なwueriesがたくさんある場合は、それらをすべて1つのストアドプロシージャに入れることができ、あなたのアプリケーションはすべての作業を行うために1回の呼び出しを行うだけです。

また、ほとんどのプラットフォームでは、ストアドプロシージャにはパフォーマンス上の利点があります。たとえば、SQL Serverでは、データベースエンジンは実行計画を最適化して保存し、処理速度を上げます。

http://blog.sqlauthority.com/2007/04/13/sql-server-stored-procedures-advantages-and-best-advantage/

http://searchsqlserver.techtarget.com/news/1052737/Why-use-stored-procedures

そして私は自分自身であると考えていても、私はこの答えのために信用を取ることはできませんが、私はこの引用が良い点だと思います： これらのリンクは、あなたの質問に答えます方程式の両辺にかなり熟練している - 専門知識のために何かがある。

アドバンテージ4：ストアドプロシージャは 通常、データベース開発者/管理者によって書かれています。これらの役割を持っている人 は、通常、より効率的な クエリとSQL文を書いた経験がある です。これにより、GUIアプリケーション開発者である は、 の機能と の機能を利用して、 というアプリケーションのグラフィックプレゼンテーション部分を利用できます。 人が に最適なタスクを実行している場合は、 は最終的により良い全体の アプリケーションを生成します。

Answer 9

ここに示したすべての回答に加えて、ストアドプロシージャはクエリの実行計画を保存する方法であることを指摘したいと思います。

アプリケーションから呼び出す一連のSQL文があるかもしれませんが、クエリを実行するたびに、SQLサーバは呼び出されたクエリが呼び出されたものとまったく同じクエリであることを知る方法がありません数分前（これはWebアプリケーションで非常に頻繁に起こります）。したがって、SQL Serverはすべての処理を再度繰り返す必要があります（クエリプランを作成して実行する必要があります）。

同じクエリがストアドプロシージャ内にカプセル化されていると、SQL Serverはそのストアドプロシージャの実行計画を保存していたので、sprocを呼び出すたびに実行計画をすべて再コンパイルする必要がなくなります。時間。 （それはsprocに渡されたパラメータに基づいてデータをキャッシュするかもしれませんが、私はこの動作の仕組みを正確にはわかりません）

Answer 10

ストアドプロシージャのセキュリティ、カプセル化、パフォーマンスなどについて他の人が述べたことに加えて、ストアドプロシージャ言語の豊富さに伴ってストアドプロシージャの有用性が増すと付け加えたい。

私はMySQLに多くの経験はありませんが、私が知る限り、ストアドプロシージャ言語はかなり限られています。

T-SQL（Microsoft SQL Server）は機能は豊富ですが、フル機能のプログラミング言語に比べていくつかの欠点があります。たとえば、T-SQLで定数値を宣言することは不可能であり、まもなく例外処理がなくなるまでエラー処理が苦労しました。パッケージのコンセプトはないので、すべてのコードはスタンドアロンのプロシージャになり、適切な命名規則を除いてグループ化することはできません。 （.NET言語でストアド・プロシージャを書くことは事実ですが）

一方、PL/SQL（Oracle版）は、複雑なデータ型、例外処理、パッケージ（パブリックセクションとプライベートセクションが別々の）グループ化プロシージャー、オブジェクトタイプ、ファイルアクセスから圧縮、そしてWebページの生成までをすべて処理する組み込みパッケージがたくさんあります。すべてのことに加えて、データベースとSQL言語とのシームレスな統合。 PL/SQLを使用してアプリケーション全体を構築することができます。純粋なPL/SQLで実装された大規模（フレームワーク）アプリケーションの例については、http://apex.oracle.comを参照してください。

Answer 11

異なるテーブルに2つの行を挿入し、2番目の挿入には最初のIDが必要です。

$sql = "INSERT INTO t1 (f1,f2...) VALUES (v1, v2...)"; 
mysql_query($sql, $conn); 
$id = mysql_insert_id(); 
$sql2 = "INSERT INTO t2 (f1,f2,id,f3...) VALUES (v1,v2,$id,v3....); 
mysql_query($sql2,$conn)l 

あなたはデータベースに2回、2つのサーバー要求/応答を行った。 INSERT、@ id = insert id、INSERTのプロセスをmy_procのサーバーにすべて格納することができれば、一度だけ行う必要があります。

$sql = "CALL my_proc(arguments)"; 
mysql_query($sql); 

Answer 12

ストアドプロシージャのコードのチューニングは、ほとんどのORMよりも簡単です。同じデータベースにアクセスし、同じことをする必要のある複数のアプリケーションがある場合、ストアドプロシージャを使用する方が簡単です。すべてのコードがストアドプロシージャ内にあるときにデータベースをリファクタリングする方が簡単です。なぜなら、変更が必要な場所を簡単に確認できるからです。通常はSSISやレポートアプリケーションのようなORMに接続しないものに対しては、格納されたprocsを使用する方が簡単です。格納されているprocsを使用すると、procの処理だけにアクセスを制限し、テーブルやビューに直接アクセスすることはできません。これは、例えば財務データの内部統制を実施する上で重要であり、不正行為を防止するのに役立ちます。

私は、1000行をはるかに超える複雑なprocsを書いています。そのようなSQLを書くためにORMを取得してみてください。次にタイムアウトせずに実行するようにしてください。