アプリ版:「スタンプのみでお礼する」機能のリリースについて

うまく意味を理解できません。
どなたか知っている方がいらしたら教えてください。
宜しくお願い致します。

A 回答 (4件)

INSERT,UPDATE,DELETE等を発行するだけでは、テーブルへの書込みが確定していません。


COMMIT(INSERT等の処理後の結果を確定)またはROLLBACK(INSERT等の処理前の状態に戻す)を発行してやっとテーブルへの書込みが終了します。
例えば、乱暴ですが下記のテーブルがあったとします。

(1)商品テーブル
 カラム:商品名・・・商品名を格納
     在庫数・・・在庫品が何個残っているかを格納

 データ:商品名  在庫数
     -----------------
     A品     10

(2)売上テーブル
 カラム:商品名・・・商品名を格納
     売上数・・・売り上げた個数を格納

 データ:商品名  売上数
     -----------------
     A品      0


で、ある日、A品が5個売れたとします。データとしては、商品テーブルのA品を5個を減らし、売上テーブルのA品を5個増やしたいとします。

 商品テーブルデータ:商品名  在庫数       商品名  在庫数
           ----------------       ----------------
           A品     10  処理後  A品      5
                     →→→           となるようにしたい。
 売上テーブルデータ:商品名  売上数       商品名  売上数
           ----------------       ----------------
           A品      0       A品      5


処理(SQL)としては、下記のような感じになると思うのですが、

  UPDATE 商品テーブル SET 個数 - 5 WHERE 商品名 = 'A品'; -- (1)
  UPDATE 売上テーブル SET 個数 + 5 WHERE 商品名 = 'A品'; -- (2)

で、(1)の処理は成功したけど、(2)の処理が何らかの原因で失敗したとします。

もし、UPDATEした結果が即テーブルに確定されるんだったら、データは下記のようになってしまいます。


 商品テーブルデータ:商品名  在庫数       商品名  在庫数
           ----------------       ----------------
           A品     10  処理後  A品      5
                     →→→          
 売上テーブルデータ:商品名  売上数       商品名  売上数
           ----------------       ----------------
           A品      0       A品      0

A品は5個売れたので在庫数は5個減ったのに、売上数には計上されていない。一体、A品の5個はどこに行ってしまったの?!ということになってしまいます。
これが「整合性」というやつです。

それで、上記処理の(1)と(2)が両方成功して初めて、テーブルを確定しないとデータが変になってしまいます。
commitは、そのために必要です。

逆に、上記処理の(1)が成功したけど(2)は失敗しちゃった時は、rollbackをしてやります。すると、(1)の処理を行う前のデータに戻って確定します。

上の説明を加味した処理(SQL)はこんな感じです。

begin
  UPDATE 商品テーブル SET 個数 - 5 WHERE 商品名 = 'A品'; -- (1)
  UPDATE 売上テーブル SET 個数 + 5 WHERE 商品名 = 'A品'; -- (2)

commit;
-- ↓(1),(2)の処理でなんかエラーが起こると即、ここに飛んでくる
exception
when others
rollback;
end;


補足:ROLLBACKはどのデータ時点に戻る?

COMMIT,ROLLBACKが発行されてから、最初にINSERT,UPDATE,DELETEが発行された時点に戻ります。

例1)
begin
UPDATE 商品テーブル SET 個数 - 5 WHERE 商品名 = 'A品'; -- (1)
UPDATE 売上テーブル SET 個数 + 5 WHERE 商品名 = 'A品'; -- (2)

commit;
-- ↓(1),(2)の処理でなんかエラーが起こると即、ここに飛んでくる
exception
when others
rollback;
end;

この場合、(2)処理中に障害が発生すると、(1)のUPDATEが行われる前のデータ状態に戻ります。


例2)
begin
UPDATE 商品テーブル SET 個数 - 5 WHERE 商品名 = 'A品'; -- (1)
commit;

UPDATE 売上テーブル SET 個数 + 5 WHERE 商品名 = 'A品'; -- (2)
commit;

-- ↓(1),(2)の処理でなんかエラーが起こると即、ここに飛んでくる
exception
when others
rollback;

の場合だと、(1)の処理後にcommitが発行されているので(1)のデータは確定している為、(2)のUPDATEが行われる前に戻ります。


commit,rollbackのタイミングは意外にも重要です。
長いばっかりで分かりにくかったかもしれませんが、参考になれば幸いです。頑張ってくださいね。
※表がずれて見にくいので、一旦メモ帳かなんかに貼り付けて読んでください。すみません。
    • good
    • 0
この回答へのお礼

非常に分りやすかったです。
どうもありがとうございました。

お礼日時:2001/11/02 16:09

データベースの種類によって記述方法が違うかも知れませんが


BeginTrans  'ビギントランス
CommitTrans  'コミット
RollbackTrans 'ロールバック
の3がっセットになります。主にトランザクション処理とでもいいましょうか
各内容は
ビギントランス:トランザクションの開始
コミット:ビギントランスから後の更新されたテーブルの更新
ロールバック:ビギントランスを実行した状態に戻す
っていう感じです。

テーブルの更新(追加、更新、削除など)をするときに
多く使用します。
これは、システムの整合性を保つためなどに大切です。

たとえば在庫管理のシステムで
入荷テーブル
出荷テーブル
在庫テーブル
があったとります。

入荷時は
入荷テーブル
在庫テーブル
を更新

出荷時は
出荷テーブル
在庫テーブル
を更新

となります。

各処理でエラーが発生したときに更新結果が途中までで終わってしまわないように
更新するときは
トランザクション処理を使用してデータの不整合を防ぎます。

※※※簡単な処理の流れ※※※※

ビギントランス

Select Case 更新処理
Case 正常更新

コミット

Case 異常終了

ロールバック

End Select

※※※※※※※※※※※※

またトランザクション処理は
データベースによってデータベースの種類って更新に制約が発生します。
どのような制約があるは、各ヘルプや専門書などで確認してください。
    • good
    • 0

データベースの時に使います。



例えば在庫管理のシステムがあって、在庫ファイルを更新して、出荷ファイルを
更新する処理があったとして

在庫ファイルを更新して出荷ファイルが書けなかった時に
在庫ファイルと出荷ファイルで不整合が発生します。
そこで異常を見つけた時にロールバック(なかったこと)し
データベースを戻します。
しかし1日の処理のどこまで戻すかを決めるのがコミットです。
コミットを切るとこれ以上は戻らなくて良いよと言うことです。
つまり
在庫ファイルを更新し出荷ファイルも更新したらコミットを切るのです。
こんなもんでどうでしょうか?
参考になれば幸いです
    • good
    • 0

データベースを利用する場合に使います。


データベースにレコードを書き込んだだけでは、反映されません。
commitを行うことによりその情報をデータベース上に反映させることができます。
何レコードかにまたがって情報を記録する場合、すべてのレコードが正しく書けた場合に、commitしてデータを確定します。
これとは異なり、途中で書き込みを失敗した場合、以前に記録したものも削除しないとデータの整合性が取れない場合もあります。このときはロールバック(ROLLBACK)を利用し、すべてなかったことにします。
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!