データベースの基盤となるトランザクションおよびストアドプロシージャ

空のセミはこんな感じです · 掲載地 2019/03/15 22:45:21

前書き

前回はSQLの基本的な内容をすべて整理しようと思っていましたが、気づけば時間が過ぎていくことに気づきました。この記事は以下に続きます。

テキスト

まず、必要なテーブルを作成しましょう

まずSQL文を実行しましょう

このコードは0001の残りを1000で、0002の残りを1000で引きます。しかし、表を作成する際に制約を追加し、残高は10以上でなければなりません。

結果は以下の通りです。

このコード実行エラーは以下の通りです:UPDATE文はCHECK制約「CH_balance」と矛盾します。この競合はデータベース「DemoDb」の「dbo」テーブルで発生します。銀行」、列「残高」。” 。もしある文がエラーであれば、もう一方の文が成功裏に実行されたかどうかが判明します。

クエリ結果は以下の通りです:

別のSQL文はエラーがないものの、依然として成功裏にコミットされません。ここで、私たちが皆さんにお明かしする内容をご紹介します。

#取引

トランザクションとは何か?
厳密には、操作が原子性、持続性、隔離、整合性を満たす場合、その操作はトランザクションと呼ばれます。
トランザクションを自動的に提出する:SQL Server上で。デフォルトでは、すべてのSQL文はトランザクションです。
トランザクション表示:各トランザクションは明示的にBEGIN TRANSACTION文で始まり、COMMITまたはROLLBACK文で明示的に終了します。

ログインが見えます。

先ほど述べたデモはロールバックで終了しているため、SQL実行は影響しません。データは成功裏に改変されませんでした。

実際の開発や応用では、通常、非クエリ文の外にトランザクションのレイヤーを設定し、実際のニーズに応じたデータの整合性と一貫性を確保します。全部やるか、全部やらないかのどちらかです。

不具合のあるSQLをログに記録するシステム変数が2つあります。 - @@rowcount 影響を受けた回数を返しますが、誤ったエンコーディング@@error返します

これら2つのシステム変数を使ってSQLにエラーがあるかどうかを判定し、上記の2つのSQL文を実行します。

ログインが見えます。

#ストアドプロシージャ

意味:実行される(複雑な場合もある)プロセスを名前にまとめ、その名前を使ってプロセスを実行すること。

> パラメータレスストアプロシージャ

>パラメータを持つストアドプロシージャ

>戻り値を持つストアドプロシージャ

データベースでキャッチしてみてください

また、前回のページ化に関する記事で触れた、デフォルトパラメータを持つストアドプロシージャもあります。

エピローグ

ストアドプロシージャは実際のプロジェクトで多く使われており、多くの古いシステムやビジネスロジックはストアドプロシージャで書かれ、その背後にいる人たちがメンテナンスを担当しています。彼らは数分で目の前の犬の頭を叩きつけたいだけです。一般的に、ビジネスロジックはコード内に書かれますが、データベースからデータが読み取られる回数とビジネスロジックはストレージプロセスで書かれます。昨年、同社のプロジェクトで非常に複雑なビジネスロジックの流れがストレージプロセスに移され、その速度は数十倍に向上しました。もちろん、特別な事情は特別に扱われます。具体的な適用は実際の状況によって異なります。

(注:上記の内容は年間の勉強ノートです。不適切な点があれば訂正してください!) ）

データベースの基盤となるトランザクションおよびストアドプロシージャ

閲覧したセクション