ストアドプロシージャは、PL/SQL言語の一連の命令です。いくつかのDBMSによって実装されたプログラミング言語であり、モデルに頻繁に適用される一連のクエリを保存し、アプリケーション層と処理負荷を共有できます。
準備済みステートメントは、実際の値ではなくプレースホルダーを使用して記述されたクエリです。クエリを記述し、DBMSによって一度だけコンパイルされ、プレースホルダーに配置する値を渡すだけです。準備済みステートメントを使用する利点は、パフォーマンスを大幅に向上させ、SQLインジェクションからアプリケーションを保護できることです。
違いは、準備されたステートメントを格納できないことです。実行する必要があるたびに、それらを「準備」する必要があります。一方、ストアドプロシージャは、スキーマに格納して関連付けることができますが、それらを書き込むにはPL/SQLを知っている必要があります。
DBMSがそれらをサポートしているかどうかを確認する必要があります。
どちらも非常に便利なツールです。組み合わせるとよいでしょう。
この短い説明がお役に立てば幸いです。
他の答えはこれをほのめかしましたが、私は長所と短所を明示的にリストしたいと思います：
ストアドプロシージャ
長所：
- サーバーがプリコンパイルするため、各クエリは、ストレートクエリよりも高速に処理されます。
- 各クエリは1回だけ記述する必要があります。異なるセッションや異なる接続間でも、必要に応じて何回でも実行できます。
- クエリにプログラミング構文（ループ、条件付きステートメント、エラー処理など）を含めることを許可します。これらは、SQLだけでは作成することが不可能または困難です。
短所
- データベースサーバーが使用するプログラミング言語に関する知識が必要です。
- それらを書き込んだり呼び出したりするために、特別な権限が必要になる場合があります。
準備済みステートメント
長所
- ストアドルーチンと同様に、クエリは事前にコンパイルされているため、高速です。
短所
- 接続またはセッションごとに再コンパイルする必要があります。
- オーバーヘッドに値するためには、準備された各ステートメントを（ループ内などで）複数回実行する必要があります。クエリが1回だけ実行される場合、サーバーはSQLをコンパイルする必要があるため、準備されたステートメントを作成する必要があるため、準備されたステートメントの準備には、返されるよりも多くのオーバーヘッドがかかります。
私のお金のために、私はストアドプロシージャを1回だけ作成してコンパイルする必要があるので、ストアドプロシージャを毎回使います。その後、プロシージャへのすべての呼び出しは、新しい接続にあるかどうかに関係なく、ループでプロシージャを呼び出すかどうかに関係なく、時間の節約につながります。唯一の欠点は、プログラミング言語の学習に時間を費やす必要があることです。ストアドプロシージャを作成する権限がない場合は、準備済みステートメントを使用しますが、同じセッションで同じクエリを複数回繰り返し実行する必要がある場合のみです。
これは、これら2つの構成要素の違いについての数か月のオンとオフの研究の後に私が得た結論です。誰かが私が作っている悪い一般化を修正することができるならば、それは評判を失う価値があります。
ストアドプロシージャはDBに格納されます-サーバーで作成したときにコンパイルされ、最適化される可能性のあるDB（Oracle、MS SQL Serverなど）に応じて...
準備済みステートメントはサーバーによって解析されるステートメントであり、ステートメントを実行するたびに実行準備ができたサーバーによって実行プランが作成されます...通常、ステートメントが複数回実行されるときに意味があります... DBサーバー（Oracleなど）および時々これらの「準備」の構成オプションは、セッション固有または「グローバル」です...
これら2つには特定のユースケースがあるため、これら2つを比較しても「良い」とは言えません...