複雑なプロシージャを作成している間、関数全体がトランザクションとして扱われます。または、関数全体を。に入れるだけの場合begin ... end。したがって、中間クエリのいずれかが失敗しても、システムに問題はありません。では、エラー報告が必要ですか？またはIF ... ELSEエラー報告をチェックしますか？（外部キー/一意などの制約が適切に行われていると仮定します）
duplicate key value violates unique constraintデータベースエンジンに依存する必要がある場合、またはデータベースエンジンに依存する必要がある場合は、自分でエラーを発生させる必要がありますか？
ビジネスロジックを開発する際にストアドプロシージャを作成する際に従うべきパターンはありますか？
私は使用PostgreSqlしていて、以前PL/PgSQLは使用していましたORM
私が理解しているように、あなたはクライアントコードから実行する関数を書いています。関数の実行全体は、明示的にトランザクションであるかどうかに関係なく、常に1つのトランザクション内にありますが、句を使用して/ブロックをBEGINコーディングすることにより、plpgsqlでサブトランザクションを使用できます。このようなサブトランザクションは無料ではないため、本当に必要な場合にのみ使用する必要があります。BEGINENDEXCEPTION
ビジネスルールを適用するために必要な不変条件を宣言的に記述することができる場合、それはほとんどの場合、トリガーで命令型コードを適用するよりも優れています。 CHECK制約、PRIMARY KEY制約、FOREIGN KEY制約、UNIQUE制約、および（PostgreSQLに固有の機能）EXCLUSION制約は、ユースケースをカバーする場合、トリガーコードの代わりにすべて使用する必要があります。
PostgreSQLバージョン9.1以降を使用している場合、開始する前に行う最大の決定は、同時トランザクション間の競合状態に対処するために使用する戦略です。2つの主な選択肢は、考えられるすべての競合を追跡してアプリケーションコードの問題に対処するか、シリアル化可能なトランザクションのみを使用して（postgresql.confファイルでデフォルトにすることができます）PostgreSQLに問題を解決させるかです。前者について私が見た中で最高の記事はここにあります：http ：//www.postgresql.org/files/developer/concurrency.pdf後者に関するリンクは次のとおりです：
http://www.postgresql.org/docs/current/interactive/mvcc.html
http://wiki.postgresql.org/wiki/SSI
SERIALIZABLEトランザクションを使用する場合、またはトランザクションを使用する場合でもREPEATABLE READ、シリアル化の失敗を一般的に処理する方法でクエリを実行する必要があります。つまり、トランザクションがSQLSTATEを「40001」または「40P01」に設定して例外をスローした場合は、失敗したトランザクションをロールバックして、最初から再試行する必要があります。クエリを実行する場所ごとに、そのロジックをアプリケーションコードに埋め込みたくありません。最近の多くの開発フレームワークでは、これを簡単に実装できるトランザクションアノテーションが許可されています。当店ではシリアル化可能なトランザクションのみを使用しており、トランザクションがそれ自体で正しいことを行うことを示すことができれば、実際に物事を単純化して知ることができます。
シリアル化可能なスナップショット分離を使用しているため、シリアル化可能なトランザクションを使用したPostgreSQLのパフォーマンスは、多くのワークロードでそれほど厳密ではない分離レベルに非常に近いことに注意してください。ブロックやデッドロックを恐れてアイデアを避けてきた場合は、そうしないでください。PostgreSQL 9.1のシリアル化可能なトランザクションには、厳密な2フェーズロック（S2PL）を使用するデータベースのような問題はありません。
完全な開示：MITのDan RK Portsとの共同作業で、Michael J. Cahillらによるシドニー大学のすべての論文に基づいて、職場での機能が必要だったため、PostgreSQLバージョン9.1のシリアル化可能なスナップショットアイソレーションの実装を支援しました。私はそれを使用している他の人から金銭的な利益を得ることはありませんが、個人的にはこれが一般的な方法であると感じています。それは、私がその機能に取り組んだ結果ではなく、その機能に取り組んだ理由であると私は願っています。